by: Thomas Meloche

Successful Delivery

It is all too common to encounter organizations that deliver software by working the development team 50, 60 or 70 hours per week prior to a release.  The most honored programmers, the heroes, are the ones who work the longest hours and deliver the largest chunks of software. Unfortunately, the systems delivered after such an initiative are often buggy, prone to crashing, difficult to maintain and support. Is this successful delivery? Were the programmers really heroes? 

The Java Factory

One bright summer day while visiting a favorite client, I found myself pulled into the middle of an impromptu sales meeting.  My client, who was working hard to improve their software development process, was telling their prospective customer about the new Extreme Programming process and how it was delivering such successful results. 

Unfortunately, my client's customer did not seem all that impressed. Perhaps the Extreme Programming process was scaring them, or perhaps it was the strange look of the giant collaborative development space we were meeting in; an abandoned factory affectionately nicknamed “The Java Factory.”  

Trying to help, I noted that we were making the software development process more of an engineering discipline. I told them we wanted predictability and repeatability in producing quality software and did not want to rely on heroic efforts.

They replied that all of their software projects were delivered as the result of heroic efforts. They proudly proclaimed that their engineers often had to work long hours all of the way up to the last minute, attempting to release a system. They seemed to like that their process demanded heroic efforts. They were bragging about it. 

I was appalled.  

Now don't get me wrong, I am all for heroic efforts. Firemen may be heroic, policemen may be heroic, soldiers and lifeguards may be heroic. Their jobs occasionally demand it. But none of these people want their jobs to be heroic. Heroics imply risk, danger and a high likelihood of failure and disaster. That is why the actions are heroic.  I don’t know about you, but I prefer not to build software with risk, danger and a high likelihood of failure and disaster.  

No Heroics Allowed

I don't want my software engineers to be heroic. Heroics are not allowed on our functioning teams. We don’t want programmers working long hours developing software in clear violation of best practices. It is not a good way to run a delivery organization. It is a good way to fail. 

Is heroic software user friendly? 

Is heroic software properly tested? 

Is heroic software going to work? How often? For how long? 

If I am flying in a plane, I don't want to hear that the navigation software was built with heroic efforts. If I am buying a car, I don’t want to hear that the anti-lock breaking software was built with heroic efforts. 

Heroics should describe soldiers, not software engineers. 

Intelligent, disciplined, careful and controlled are words that should be used to describe our software development efforts, along with inventive and creative, but not heroic. 

Managers who describe their software projects as heroic should be ashamed. The entire Menlo Institute is dedicated to eradicating the idea that software development should be heroic. 

Hard working, yes. 

Successful, yes. 

Heroic, no.

Postscript

The manager who proudly described his software process as heroic produced payroll software, so you better check your pay stubs.  Does heroic payroll software calculate your pay accurately?

Interested in Learning More?

Tom, send me Rich's free white paper "Secrets of Software Success: Adapting Projects to an Accelerated Society"

We will not resell your contact information.

We hate spam as much as you do.

Privacy Policy: No Resale Zone.  Spam Policy: No Spam Zone.