What's Wrong with SDLCs and the 3 Rules of Moron-dynamics

Introduction

Software Development Lifecycles (SDLC) and the 3 rules of moron-dynamics.

Author: Tom Shope

Ever notice how many SDLCs are out there? There are dozens of them. RUP, TDD, XP, Waterfall, Spiral, Model Driven, Top Down, Bottom Up, Evolutionary, etc. Hundreds of books have been written. There are classes, tutorials, and entire software packages dedicated to them. Some companies actually create their own in house. Most have many phases and steps. Most produce reams of documentation. Why so many? Simple, they don’t work! By that, I mean that none of them solve the problem they claim to solve, which is how do you take a group of programmers with varying degrees of skill and produce high quality complex applications and systems in a timely manner.

It is my contention that most formal SDLCs actually have the unintended result of reducing productivity and often completely stifling development projects. In fact, I would say that most projects that are released and useable achieve this in spite of and not because of the SDLC used.

Using a formal SDLC to solve the problem of producing quality software has a huge flaw. At its foundation, this premise is based on a fallacy. The fallacy is that you can get quality and timely code from a mediocre programmer. This is simply not true. Do you think you could reproduce the Sistine chapel? Hopefully you answered “no”. Well, what if we documented each step that Michelangelo engaged in during his process and you repeated those steps yourself? Still “no” right? This brings us to “Shope’s 1^st rule of moron-dynamics”:

You cannot substitute process for talent or skill.

Management generally loves the idea of an SDLC because no longer do you have to hunt down and nurture the few talented and productive software developers you are able to find. Anyone can be a great software developer as long as a great SDLC is rigidly enforced. The problem with this is that great software development is a mixture of art and science. It absolutely cannot be reduced to simple steps that a moron can follow. That ignores the art portion of the process. There is a reason people often use the word talent when discussing software developers. Talent is generally something that cannot be learned.

On to “Shope’s 2^nd rule of moron-dynamics“:

A software developer’s productivity is inversely proportional to his use and knowledge of formal SDLCs.

If you want to hire a highly productive software developer, find one that sails through a tough technical interview, was making top dollar at his last job, and most importantly, seems to have a low opinion of all SDLCs. In fact, the person should sneer or even mock the idea of formal rigid adherence to SDLCs. Hire that guy and you will not be sorry. Am I saying that all software developers who know and love SDLCs are morons? No, definitely not, some are quite brilliant; they just usually are not highly productive software developers. If you have been doing this long at all, you have met the type of developer that knows everything and can speak for hours on the intricacies of an SDLC or can produce reams of elaborate architecture designs, but never seems to actually produce much of anything. You know what I’m talking about. My point is that many brilliant and highly knowledgeable software developers are quite unproductive.

But wait you say. Surely there is value in following a well defined process for software development. Surely we can benefit from good requirements gathering, good design, good testing, etc. My answer is, yes of course, these stages of development are utilized by productive software developers. But truly brilliant, skilled, and highly productive software developers do not need Mr. Booch or Mr. Rumbaugh to tell them how to do these things. At its simplest form, an SDLC is simply:

• What do I need to create? (requirements)
• How can I code this? (analysis/design)
• Code it (development)
• Make sure it works (test)
• Give it to people to use (release)
• Make changes if they complain (maintenance)

Do we really need some brilliant PHD to tell us this? Great software developers do not need that help. Thanks anyway.

And finally there is “Shope’s 3^rd rule of moron-dynamics”:

Rigid adherence to a formal SDLC slows development and reduces quality.

This is because, by having a formal SDLC in place, you force the few truly talented and highly productive developers to adhere to a gruelling process that they do not need and from which they derive little benefit. SDLC processes use up large amounts of the productive developer’s time on useless unnecessary tasks. This 3^rd rule is also true because it allows management to assign to the project many people that are not competent to develop software of any kind, but who are more than competent at following the rules, procedures, and deliverables of the SDLC. In other words, they can write a requirements document or produce a test plan, but that cannot design and code quality software. These people further reduce the productivity of the few truly skilled software developers on the project. Furthermore, management is smugly happy with all these unnecessary people, calling meetings, forming committees, getting feedback, conducting studies, producing reams of documentation nobody ever reads and sending hundreds of emails. “Look at all the activity on my project” they say to themselves. “We sure are making good progress”. How ironic.

To recap Shope’s 3 rules of moron dynamics:

• You cannot substitute process for talent or skill.
• A software developer’s productivity is inversely proportional to his use and knowledge of formal SDLCs.
• Rigid adherence to a formal SDLC slows development and reduces quality.

So if SDLCs are so ineffective, why does management love them so much? Excellent question. There are numerous reasons for this phenomenon:

• Management does not know that all this SDLC process and formality is reducing productivity because generally there are a few superstars on every development team that will eventually overcome all the SDLC obstacles and frustrations to produce something useable. In other words, the few truly talented developers will produce working software in spite of the burden of the SDLC process.
• A formal SDLC gives control back to management. No longer does management have to kowtow to the brilliant software developer primadonna. Management knows how to develop software. There is no mystery, simply follow the SDLC process. The SDLC shifts control from the software developer to the manager.
• A formal SDLC allows management to treat software developers as interchangeable resources. Since you can hire pretty much anyone with the right background and just have them rigidly follow the SDLC to produce quality software, you no longer need to be worried about hiring or keeping the right people.
• A formal SDLC makes management look good to their superiors. Senior management can be shown the SDLC process in action. They can be shown the flurry of activity that the process generates. They can be shown any of dozens of impressive looking SDLC documents. Development management can justify to senior management the expense and time of software development by pointing to the elaborate SDLC. Of course it takes many people and lots of time, look at all this stuff we have to do…
• And finally a formal SDLC gives management something to do. There are many meetings to attend, documents to review, committees to form, user feedback to seek, etc. Management is a flurry of activity with a nice fat SDLC in place.

In conclusion, I will recommend a plan of action for management to eliminate this problem.

• Identify the superstars on your staff. These are the people that are talented and highly productive at software development. Management should already know who these people are.
• Ask the superstars to identify unproductive staff members. There should be many identified. This percentage should not be less than 50% of the staff and may be as high as 80%.
• Fire the unproductive staff members.
• Significantly raise the salary of the superstar staff members.
• Eliminate entirely any SDLC in place. (This is the toughest step as this is akin to asking a typical development manager to chop off his arm.)
• Adopt a new development strategy in which the superstars are given 50,000 foot requirements and are asked to deliver the software as quickly as possible using whatever strategy they deem appropriate.
• All documentation is now optional.
• All meetings are now optional.

This strategy should result in a large increase in productivity and surprisingly, quality as well.

History

• 3^rd January, 2007: Initial post