Click here to Skip to main content
15,867,308 members
Articles / All Topics

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

Rate me:
Please Sign up or sign in to vote.
3.75/5 (37 votes)
3 Jan 2007CPOL7 min read 76.9K   14   37
This article discusses the fallacy that SDLC methodologies provide a solution to quality software development.

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 1st 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 2nd 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 3rd 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 3rd 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

  • 3rd January, 2007: Initial post

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Web Developer
United States United States
Tom Shope is a .NET software developer. He has been developing software for the windows platform since 1990. His employers have included IBM, Fidelity Investments, Dun & Bradstreet, Texas Instruments, as well as several small software shops.

Comments and Discussions

 
Question[My vote of 1] This article is a joke... Pin
verger5-May-14 19:41
verger5-May-14 19:41 
GeneralI can feel your pain Pin
miroslav6519-Mar-09 5:38
miroslav6519-Mar-09 5:38 
GeneralCreasar & Big A** Agree Pin
Creasar31-May-07 6:40
Creasar31-May-07 6:40 
GeneralOptional Meetings - I don't think so. Pin
nickOppen13-Jan-07 15:49
nickOppen13-Jan-07 15:49 
GeneralFire the unproductive developers Pin
Maneeshk12-Jan-07 18:51
Maneeshk12-Jan-07 18:51 
Generalreverse the roles Pin
RedSunBeer12-Jan-07 5:00
RedSunBeer12-Jan-07 5:00 
QuestionWhat about mission-critical software ? Pin
FlyByMike11-Jan-07 6:43
FlyByMike11-Jan-07 6:43 
GeneralMethods and Techniques are needed Pin
DRK PMP10-Jan-07 15:44
DRK PMP10-Jan-07 15:44 
GeneralRe: Methods and Techniques are needed Pin
agile csm19-Jul-07 14:46
agile csm19-Jul-07 14:46 
GeneralArt and craft Pin
Boudino10-Jan-07 0:20
Boudino10-Jan-07 0:20 
GeneralAnalysis is the the problem not the SDLC Pin
mtbbiker9-Jan-07 22:46
mtbbiker9-Jan-07 22:46 
QuestionCan you say Cowboy? Pin
Onehip9-Jan-07 17:50
Onehip9-Jan-07 17:50 
Why blame poor management on the SDLC? The SDLC is. It exists independent of any one developer. As the article itself states every good developer will follow the steps outlined by the hundreds of different SDLCs. Abandonment of the SDLC is taught in most schools as code and fix and will result in poor code and unusable applications.

Really the processes derived from the SDLC and the management of them is the necessary business attempt to produce an environment that can produce solid stable software applications repeatedly. In other words it is the butter to our bread. A good management team will provide and require the framework that allows the great programmers to be great and pass that knowledge on to others in the TEAM. Unless of course your too selfish or lazy to work to make the whole group better.

The attitude of this article is that of the cowboy and is in my experience inevitably dangerous. The application generally becomes full of developer candy and without meeting the users requirements. Reasonable process is a necessary and beneficial evil.


JMM
GeneralOooh I don't know Pin
Michal Blazejczyk9-Jan-07 9:45
Michal Blazejczyk9-Jan-07 9:45 
GeneralFinally! Pin
Mark James Newman9-Jan-07 6:31
Mark James Newman9-Jan-07 6:31 
GeneralI've got to agree Pin
ksalvage9-Jan-07 1:09
ksalvage9-Jan-07 1:09 
GeneralSCRUM Pin
wallismark8-Jan-07 22:59
wallismark8-Jan-07 22:59 
GeneralRe: SCRUM Pin
agile csm19-Jul-07 14:48
agile csm19-Jul-07 14:48 
GeneralAvoiding cowboys - giving control back to management Pin
Chiew Heng Wah8-Jan-07 15:28
Chiew Heng Wah8-Jan-07 15:28 
GeneralOne cavaet Pin
MAJackson4-Jan-07 9:56
MAJackson4-Jan-07 9:56 
GeneralRe: One cavaet Pin
Thomas Shope5-Jan-07 4:51
Thomas Shope5-Jan-07 4:51 
GeneralRe: One cavaet Pin
MAJackson6-Jan-07 14:25
MAJackson6-Jan-07 14:25 
GeneralRe: One cavaet Pin
camainc8-Jan-07 5:14
camainc8-Jan-07 5:14 
GeneralRe: One cavaet Pin
MAJackson8-Jan-07 6:45
MAJackson8-Jan-07 6:45 
GeneralTotally agree Pin
djtcp3-Jan-07 12:15
djtcp3-Jan-07 12:15 
GeneralGreat Article Pin
willcoxson3-Jan-07 9:00
willcoxson3-Jan-07 9:00 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.