Creating software is unlike laying bricks, driving a truck or assembling manufactured items. For these jobs it is easy to measure progress and forecast completion. Writing code is like a treasure hunt. With bricks you can count the number set in a given day and figure out the total number of days to complete the job. With a treasure hunt it might take a day to find the first five items. That doesn’t mean it will take a day to find the last five. In fact, it will probably take a lot longer than a day to find those last items because the easiest are likely to be discovered first, and the hardest last.
During the average software development project 50% of time is spent debugging. With a website that means the software must be tested on all common browsers, including desktop, tablet, and mobile versions. Code should be tested with W3C validators because standards compliance helps ensure compatibility with future browsers that don’t even exist today. All this testing takes time, and doing a good job means fixing every bug, including those that the average user might never notice. The better the job, the longer it takes.
Setting artificial deadlines on software projects tends to produce low quality work and drive away the best developers. It’s a story we’ve seen many times: a manager picks a date on the calendar, and applies the same discipline they would use in a physical business. As the development team works longer hours, their productivity goes down, and as the deadline approaches they are forced to ship “brittle” code that’s expensive to maintain, hard to extend, and full of bugs lurking below the surface. Competent developers don’t like to work under those conditions, so they leave the project.
That’s why we have a “no deadlines” policy for web development projects. Of course, the software users sometimes have real world requirements that may fix a date on the calendar. On a particular date we can deliver whatever code we’ve completed and thoroughly debugged, but we can’t guarantee that all features and pages will be completed. A good website lasts five years or longer. We believe in taking whatever time is necessary to do the job right. Ask yourself one question: will the old website suddenly cease functioning on a particular date? Probably not. So why have a deadline?
For additional perspective, I recommend by Michael Wolfe’s essay Engineering Management: Why are software development task estimations regularly off by a factor of 2-3?.
For additional information, please contact Hochman Consultants.
