Dealing with Haste
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software... Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
The solution to haste is obvious in hindsight. Ruthlessly prioritize the work so that the valuable stuff can get delivered early, before any of the less-valuable stuff. Then work at a sustainable pace so that the team can take the necessary time to think and work through the issues that arise.
A strange aspect of this solution is that it's nothing new. Tom Gilb called it evolutionary delivery in his 1988 book Principles of Software Engineering Management (Addison-Wesley, ISBN 0-201-19246-2). The concept of evolutionary delivery is now embraced by the term Agile software development. Maybe now that it has a catchier titleafter all, who doesn't want to be Agile?projects will be planned on the basis of incremental delivery.
Unfortunately, it's unlikely to be that simple, because haste is affected by ignorance. All too many organizations delay starting a project until it becomes extremely urgent. Rather than succumbing to the temptation to attribute this behavior to stupidity, I prefer to attribute it to management's ignorance of the effects of haste on the quality of software. Now, whenever I hear of panicky, rushed projects, I always wonder how much effort it took to manufacture the crisis and who was asleep at the wheel at the time.
There isn't much more to say about haste, other than that it's a great way to produce rotten code. Creating great software takes time, so the time has come to push back against crazy, urgent projects. One subtle way of doing this would be to give the project manager and project sponsor a copy of Tom DeMarco's book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency (Broadway Books, 2001), which catalogs the problems associated with haste, inefficiency, and busyness.