The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Mark Shuttleworth's nice article on funding opensource projects

http://mscom.rabbithole.co.za/archives/4

It's a nice discussion on the issue that geeks don't like shortcuts if they aren't forced to, and they will prefer to build the framework to build the framework first, etc etc.

And the problem is that the open source geeks are just as usual.
Lost but recovering
Tuesday, February 14, 2006
 
 
Is it just me, or was that article very hard to read?  Maybe it was the font, the text size, the fact it was justified, or just plain old poorly written.
Should start working...
Tuesday, February 14, 2006
 
 
I learned nothing from it. So he hired a couple geeks and set them free to wander off into lala land. What did he expect without putting anyone in charge?
SumoRunner Send private email
Tuesday, February 14, 2006
 
 
How many times have you heard programmers say they can't get anything done because management is always screwing everything up, and if they could just be left alone have it THEIR way, the product would have been done in half the time with twice the features.

I've seen that mantra countless times on JOS.

Perhaps he sought to find out if there's any truth to that.  I guess he found there isn't.

Tuesday, February 14, 2006
 
 
"How many times have you heard programmers say they can't get anything done because management is always screwing everything up, and if they could just be left alone have it THEIR way, the product would have been done in half the time with twice the features."

This concept misses one important element to become a reality: an architect. IOW, a technical person who will steer the project and avoid wandering off to what are people interested in technically.

As I understood the article, the problem with his team was that they went off resolving problems having nothing to do with the project's aim, instead doing things that they really were interested in. A technical head would prevent that and direct the team's enthusiasm and skill on the right track.

Where management usually does screw up the team is in imposing senseless limitations and generally messing up with the team in various ways (read Peoplesoft for a good overview).
Berislav Lopac Send private email
Tuesday, February 14, 2006
 
 
"Perhaps he sought to find out if there's any truth to that.  I guess he found there isn't."

So his findings are universally true and relevant? While his summary is a fascinating read, this is just one team of hundreds of thousands of teams. Your mileage will certainly vary.

Indeed, without hearing the other side of the story, we really can't take anything from this. e.g. Often management feels that the foundation of an application (which would take X time) is unnecessary frill-work, and instead one should be focused on "getting it done". The end result is something that takes X/2 for the first form, and then X/2 for the next form, and then X/2 for the next, and the next, and the next, and the next...  Whereas letting them build the proper foundation would have yielded X/10 for each additional form. Obviously these numbers are made up, but developers have fought back against management regarding this sort of compromise for time eternal.

Of course there are a lot of developers, and teams, that will basically screw the pooch if they don't feel that they're being overseen, and they aren't really accountable for their time.
Dennis Forbes Send private email
Tuesday, February 14, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz