-
Website
http://www.inc.com/ -
Original page
http://www.inc.com/magazine/20071101/how-hard-could-it-be-five-easy-ways-to-fail.html -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
All Comments
Every complex software system is built in layers, where Version 2 of a system is built upon the solid foundations of Version 1, as well as the foundations of other solid modules. Most of the major components in WinFS were experimental beta versions, from SQL Server 2005 (this was in 2002), the C# UDF`s, including managed C# built on experimental visual studio features, to the new wave of XML support in the database and office products. Meanwhile, it was absolutely assumed that everything had to be backward compatible with old-n-busted versions. Add to this the mantra that eventually 350 million computers would be running vista, including grandmas, with a built-in SQL server database, with no DBA, that can never fail... Unrealistic expectations.
1. Requirements actually are the number 1 cause of software project failures, not the developers involved. Review the Standish group`s Chaos report for one of my references here.
2. Requiring superstar developers because they`re 10 times more productive than the "merely excellent developers" is equivalent to requiring heroes to do your work. I`m not sure why Joel thinks it is OK to have this requirement for heroes while heroics aren`t recommended. Reality is that software projects can be done reasonably without heroics or heroes.
3. Requiring one-size fits all estimation practices is inappropriate. Tailor your estimation to your project. In some projects, it may be appropriate to have your developers dissect the problem down to 2 day or less increments of work. On others, this may stifle creativity. Whatever you do, however, be sure to estimate risk and rework because there will always be surprises, no matter how detailed you get in your estimates. Once you`ve got your estimates, take a step back and roll-up the numbers before establishing project milestones, creating a schedule, and presenting that to project stakeholders.
Microsoft in particular is a victim of its own success -- having to support a bazillion kinds of hardware and be backward compatible at the same time. It`s an impossible task.
Joel sounds like a really intersting guy, but I disagree with nailing a developer down to milestones. I`d rather develop something a few small pieces at a time, and be able to demo that to the stakeholder. And if the stakeholder has a release date in mind, then I`ll work towards that date, working my way down the feature list, and whatever makes it into the release by the deadline is whatever makes it into the release.
I`d rather deliver a slimmer, well-built piece of code, than something we smashed together to meet some deadline that no one wants to touch afterwards. As Joel himself says, it`s a marathon, not a sprint.
Then Joel says: "but I do this cautiously and build an extra three weeks into the schedule for the incoming developer who`s learning the new code, and an extra week for the outgoing developer"
Come on, which is it? Could it be that software development naturally breaks down into week-long chunks? Certainly sounds that way from quote #2, else Joel would have added 15 days for the learning curve, which ends up sounding ridiculously precise. In my experience, single days (or hours) have far too much variability in their level of productivity to be useful measures, whereas weeks have much less variance. Hence, schedules in weeks are wrong less often. Requiring schedules in days or hours is just another form of Mistake #3.
pretend you`re interviewing for a top position at m$, and the high-IQ question they ask you: "Define winFS as a success"
Iterations should be planned out with early iterations having explicit project plans (like version 0.1) and later iterations just having milestones as explicit planning is a bit of a waste of time as it only would work if iteration 1 goes perfectly in terms of client response and it never does.
Bruce
I find this comment funny, in the context of Agile software development. IMHO, it`s only a marathon if you look at it as such. I prefer to look at a project as a series of small sprints. In the end, you get the same output. The difference is that one is much less daunting to think about. Divide and Conquer.
1. You have to have a market. The coders who put together all the spreadsheets that competed with Microsoft Excel didn`t all fail technically. They ran into Microsoft`s marketing muscle.
For embedded code, it isn`t enough to have technical success. Somebody has to want to buy the airplane or telecomm gear you`ve made.
2. It helps greatly to have managers who know what they are doing. I`ve written code for people who turned out not to know what a computer really is, nor what software is. People like this drive projects over cliffs.
3. It helps greatly to have customers who know what they want. It is quite hard for computer users to get used to a new system, especially if the new system is just barely working. It is easy for them to throw an expensive system in the trash and blame the software. It is impossible for them to know if a product is going to start working for them next week, or never.
4. Sometimes it isn`t much of a cure to involve the users in the development; They have their own jobs to do and can`t spare the time to work on creating software.
5. Software developers themselves don`t know if they`re incompetent. I`ve taken over half-finished projects from other coders and found hard-working, diligent souls can produce an utter mess. And neither they nor their bosses had any idea how incompetent they were.
How can you say that `...a bad team of developers tends to be the no. 1 cause of software project failures...`? Who says? I usually enjoy reading your articles but I have noticed that you tend to make these wild claims without including any reference to support your claims.
Failed software projects are usually never a result of any one single cause and blaming the large percentage of failed projects on an imaginary population of `bad developers` is both naive and irresponsible. In my experience bad developers are either fired or delegated to making coffee for the rest of the team. They usually don’t last long in any one organization and tend to bounce from one job to the next.
So which of these is the reason Copilot is a failure? Try logmein.com... it`s much better... and free!
A good opinion but I disagree with you when you talk about that the first mistake are mediocre team of developers because I dont`t understand what are a mediocre team for you.
I think that a mediocre team is a team that don`t want read, don`t want work, don`t want learn, don`t have atitude. If a developer have little bit technical knowledge but want to learn and have atitude it`s a very good developer and I want he in my team and he is not a mediocre developer.
This idea of having to breakup milestones into daily or hourly chunks also seems ludicrous to me. As an individual developer I often try and work out what I want to have done by the end of the day, but to manage this into some kind of project plan is not possible
Software developers are artists not scientists, and until this is really understood and managed as such, if "management" is really required, software development efforts will continue to "fail".
When you ask an artist to create a work of art, such as a sculpture or a painting, would you ask for a schedule? No. You would wait until the the artist believes he has finished.
I believe we need to shift towards the idea that software development is not something that can be controlled and managed precisely, but instead is an artistic process given freedom to `evolve` into a solution over a flexible time scale. i.e. think art and not science.
Right:
40 hour (max) work weeks. I like what the previous commenter said about "bursts of inspiration", followed by comp time. You can`t burn your devs out and expect results.
Superstar developers. Imagine any other challenging field that requires intelligence, experience, and perspective, and hearing management say "We can get away with mediocre staff." Mediocre developers = mediocre (or worse) results.
Wrong:
Requiring developers to estimate out every nth detail to the sub-day level. This is just plain dumb, because by the time you get the estimates done the client has shifted the goalposts to reflect either (a) their new understanding of the capabilities of the software, or (b) their changing business environment, or (c) their modified budget, or (d) etc. etc. etc.
Joel has some crazy pathological aversion to agile software development methods, but they are sane and they work.
http://theschmitzer.blogspot.com/2007/10/role-b...
http://gcs-tech.blogspot.com/