Joel Spolsky’s article in the November issue of Inc. magazine lists five ways to make a software project fail. Joel’s arguments are well-known in the software development community, but probably not to the majority of Inc. readers. Professional programmers will also recognize a few big swipes at agile programming methodologies. Joel doesn’t mention agile by name but if you’re paying attention you know what he’s criticizing.
Mistake No. 1: Start with a mediocre team of developers.
Hiring superstar programmers is a recurring theme with Joel. We’d all like to hire, work with, and be known as one of “the best developers,” and not just one of the “merely excellent,” or worse. There’s enough self-promotion and hubris in Joel’s claim to put me off. In order to attract and identify the cream of the programmer crop you have to be pretty elite yourself, right? Everyone at Fog Creek Software (Joel’s company) is, by Joel’s definition, one of “the best.” Many other companies claim to hire only the best. But there’s no objective way to identify the best programmers, or to separate the mediocre from the merely excellent. I’ve read about Fog Creek’s interviews, and I think their internship program is a good idea more companies should try. But just calling yourself one of the best programmers because you work at a place that only hires the best is pretty much one hand clapping.
If Fog Creek actually reviews 400 candidates for every full-time job opening they are either getting a lot of unqualified candidates, just like everyone else with a job opening, or they are somehow attracting a lot of really good programmers and getting their pick of the litter. If you look at Fog Creek’s products and read about the development tools they use, you have to wonder how they are getting so many top-notch programmers kicking down the doors to get in.
Joel does make one on-target observation that deserves a lot more discussion: “In all fields, from software to logistics to customer service, people are too nice to talk about their co-workers’ lack of competence.” The psychology that allows the mediocre and merely adequate programmers keep their jobs year after year is a complex combination of politeness, guilt, and hope. In my experience I’ve worked with a few truly incompetent programmers, but mostly I’ve worked with programmers who are just a lot less experienced than the best programmers in their company. Everyone has to start somewhere — we were all mediocre programmers once. Not every company and project needs or can hope to attract the best programmers anyway; Microsoft recognized that fact a long time ago and that’s why Visual Basic is the most popular “enterprise” development tool.
Mistake No. 2: Set weekly milestones.
Here’s where Joel kicks agile techniques to the curb. The near-horizon milestones, evolving backlog, and short sprints that characterize agile programming are the opposite of the waterfall method Joel describes: Detailed plans and schedules, considering every detail. Joel does understand how programming according to the waterfall method goes wrong. That’s why agile techniques were invented.
Setting aside the obligatory kitchen remodeller analogy, let me dissect Joel’s arguments:
[S]oftware developers are building things that they’ve never built before. If they had, they’d just sell you another copy of the CD-ROM.
Joel knows as well as I do that there’s a lot of territory between canned software on a CD-ROM and building something completely new and unfamiliar. Most — nearly all — programmers write the same kind of code over and over again throughout their careers.
So rough estimates are impossible.
Programmers can get good at estimating the equivalent of a kitchen remodel; I can estimate an e-commerce site’s shopping cart work even though I will be writing it custom for the site. A rough estimate may well be impossible for something no one has ever done before, but those kinds of projects are the exception. If the project manager and team can’t come up with some rough numbers they probably need to hire someone to help them, someone who has experience in the application domain.
They need to draw up detailed plans before they start writing code. Whether you’re the customer or the developers’ manager, your job is to make sure they come up with that blueprint.
A detailed plan for a kitchen remodel takes a few hours to draft and derive materials and time estimates from — making the plans is orders of magnitude simpler than doing the actual work. Software isn’t like that. The detailed plan for a non-trivial program is as complicated as the program itself. If every problem is solved enough to estimate the code in hours, if every logical module is described, and if every contingency is anticipated and planned for, the code will almost write itself. The problem is that people are not any better at making detailed plans in English or flowcharts or UML than they are doing it in a programming language. As programmers demonstrate every day, human beings are not very good at making complete, detailed plans for big, complex, poorly-understood projects. Programming is not like a kitchen remodel or building a bridge, and I think Joel is pandering to Inc.‘s readers just a little.
When you ask developers for [a detailed schedule], however, many of them will respond by creating a schedule that breaks pieces of the process into weeks. This may seem perfectly reasonable, but it’s not. If you let a software team submit a schedule with big chunky estimates of time (by big I mean more than two days of work), you can be almost certain that they’re not considering every detail that needs to be implemented, and those details will add up to a huge delay.
Joel’s right — a complete, detailed plan shouldn’t have tasks estimated in weeks. That isn’t how agile works, though, and I’m sure Joel knows better.
Joel quotes Edward Yourdon, who devoted much of his career to figuring out how to break big projects down into pieces small enough to understand and estimate. I’ve seen it work a few times, but usually the big detailed plans and estimates part ways with reality fairly early on. Project managers are constantly revising the plan on-the-fly, or the team is ignoring the plan because it isn’t realistic. For a lot of projects it makes more sense to identify the closest milestone, figure out how to get there, plan just that much work, and estimate it. The faster feedback loop keeps the project from getting too far into the weeds and customers get frequent assurance of progress.
Mistake No. 3: Negotiate the deadline.
No argument with that one.
Mistake No. 4: Divide tasks equitably.
[W]hen one developer steps in to replace another, it’s reasonable to assume that the new one will work at about one-tenth the speed. John’s going to have to spend untold hours figuring out all the things that Mary already knows about her area of code. And John can’t fix Mary’s bugs as fast as Mary can because Mary knows where all the hidden traps are.
Joel’s right, programmers are not interchangeable. Adding or shuffling people around during the project will almost always make things worse. However it’s not a good idea to create single points of failure in your team if you can help it, and no amount of documentation or “cross-training” will make John better at fixing Mary’s bugs.
An agile solution to this problem is pair programming. Even if pair programming is too extreme for your tastes, having a team that works in short sprints, discusses and synchronizes their work every day, and works form the same task backlog can go a long way. The best way to use the people on the team and to help them gain experience is to have them work together as much as possible. Even without keyboard sharing it’s better to have programmers mentor and learn from each other than to let each carve out a domain no one else understands.
Mistake No. 5: Work till midnight.
Joel restates the thesis of The Mythical Man-Month using a pregnant walrus story. Inc.‘s entrepreneurial readers — some of whom will hire programmers eventually — would be better served by a “buy” recommendation for Fred Brooks’ book.
Joel advises his readers to “[D]emand fine-grained time estimates from the developers. Yes, it’s difficult for developers to predict how long it will take to build a new application. That’s why they need to create a reliable blueprint before every project.”
As a sometimes freelance programmer I don’t want to work for a client who takes Joel’s advice. Unless my client has some good experience developing software he isn’t going to recognize a realistic schedule or a complete, detailed plan anyway. About half of the freelance gigs I get are cleanup jobs, fixing and finishing the half-baked effort of some other programmer. I get to see the detailed plans and estimates they wrote up to get the job. Their proposals look professional and convincing, but because the client couldn’t understand the plans and only looked at the bottom line — delivery date and total cost — the whole exercise was a ritual that has little to do with reality.
I want to add a couple of my own mistakes to Joel’s list:
Mistake No. 6: Keep your customers and users out of the loop
If you make a big plan and schedule up front (the BDUF or Big Design Up Front methodology Joel espouses) and then don’t check in with your clients or users until you deliver, your project will seem successful until the very end, when the customer tells you that what you delivered isn’t what they expected. That happens because even the best software designs and plans aren’t as comprehensive as either party wants to believe. No matter how detailed and complete you think your plan is, the customer will have a very different picture in her head. The kitchen remodeller will usually get regular feedback as the homeowner watches the work proceed. Programmers need regular feedback, too, because small misunderstandings early in the project can put the end result way off course. Even the old-school Yourdon understood the value of frequent reviews to keep the project on the rails.
Mistake No. 7: Don’t use common tools and technologies
Whenever a programmer complains that language X can’t do what they want it to do, I know that I’m probably listening to one of those mediocre programmers Joel warns us about. When a programmer tells me they’re making their own language or text editor or markup language because the available tools just aren’t good enough, I know I probably don’t want to be involved in their project. When a programmer claims that he can only use some exotic language or technology, I will demand convincing proof before letting his vanity get the best of me and the project.
I have worked on projects that actually needed new tools written from scratch, but those projects are rare. Most of the time programmers are too lazy to learn about available tools, or too full of themselves to recognize that the tool chain they’ve cobbled together is a house of cards that will be a support problem for years.
Joel ends his article with “In the technology world, it’s better to view a big project as a marathon, and not a sprint.” Zing! Take that agile people!
Comments
Robz, 26 October 2007 at 8:22 am
Great post. I like the additional mistakes. Like you mentioned, not including your customer in the development process is a good way to ensure you deliver something they do not want.
Reading Joel’s article again, I’m not fully sure if I see an attack on agile. My frame of reference for agile isn’t a pure vanilla version of agile either though (like I would consider XP). We see the value of some design up front and then use scrum project management and two week iterations.
When Joel said he didn’t think you should estimate in weeks, I ignored that because we estimate first in story points, and then hours (not weeks). We think of features in story points, and then break them down to all tasks necessary to get that done. The tasks themselves are estimated in hours. I do agree that you can’t get someone to estimate very well in weeks or even days. If you ask them how many hours it is going to take them, they are more likely to think about the details.
Steve McConnell has a great post on how horrible developers are at software estimation: http://blogs.construx.com/blogs/stevemcc/archive/2007/09/23/building-a-fort-lessons-in-software-estimation.aspx
David Sidlinger, 27 October 2007 at 5:51 pm
That last rule wouldn’t be a jab at Fogcreek inventing their own programming language, would it. 😉
http://www.joelonsoftware.com/items/2006/09/01b.html
ferris oxide, 28 October 2007 at 7:56 pm
It’s official.. Joel has ‘jumped the shark’
raveman, 28 October 2007 at 10:00 pm
i also hate the “best developers” bs, if they were the best they wouldnt be at Fog Creek (i only hear of it because of the blog).
I disagree with both of you about competence, its just programming. I might know RegEx and you dont, but you can always learn it. I only met one programmer that was super-bad and couldnt understand simple new thing.
Mistake No. 7: Don’t use common tools and technologies I acutually was offered a job that used it owns hibernate and struts (they even said on interview that its better, so arent they also the best developers?). They really wanted me, but … it was cool to build your own frameworks back in the days, but now you should drop it and use stuff that everybody knows/should know.
martin english, 13 November 2007 at 5:59 pm
re superstars…. Can’t remember where I read it, but doesn’t everbody hire the best 10% (of applicants) ?
To paraphrase, if google hire the top 10% of everybody, then yahoo hire the top 10% of those left, and MS hire the top 10% of those left after that, and, say, IBM hire the 10% of whats left after THAT….
You’re already in the bottom 2 thirds….
Peter, 24 November 2007 at 7:23 am
For anything that’s a fixed-price project (as most clients understandably want) the planning which you have a dig at in section 2 is something I don’t see how it can be avoided. If the client’s signing for a certain amount, I want to be damn sure they’re not changing their mind every couple of weeks – at least the features and scope have to be defined. It’s not clear which level you’re saying is too much scoping.