Your Guide to Fast, Fail-Proof Software Development

Why doesn't Moore's Law apply to software development? If it did, every 18 months or so applications would be twice as fast and/or be built in half the time. The reason Moore's Law or any ordered progression of improvement doesn't apply to software development is that very few people are working on intellectually improving it and almost no one is applying the results of intellectual studies to it.

For instance, Steve McConnell's Code Complete, Second Edition presents some very reasonable principles. But, as I go through it now, I wonder if any manager has read it, and if so, why none of its ideas are being applied.



Prerequisites to Building Software Fast


  • Use a team that has experience working together.
  • Roles must be highly specialized.
  • Do good, advanced design work.
  • Construct a solution by risk and importance.
  • Storyboard the construction plan.
  • Specialists must work in parallel, building to black boxes.
  • Keep black boxes simple.
  • Insist on unit and system testing.
  • Manage change aggressively.

Depend on Experienced Teams




Eschew Generalists




Advanced Design Work Is Critical

Advanced design work means that architects, analysts, and designers get together and do a bunch of analysis and design work before the programmers are invited to the show. Think of the design team as the party planners: Plan the party and hang the streamers before the programmers start swilling beer and eating all the hors d'oeuvres.


Construct by Risk and Importance


An important additional concept here is that if the software looks promising and solves most of the business case, management will support funding the project's second wind, which means a greater likelihood of getting the whole feature set in production.

Storyboard the Construction Plan Publicly




Define Macro and Micro Schedules







Your Guide to Fast, Fail-Proof Software Development

Massive Parallelism Is Possible

Massive parallelism means that multiple tasks are occurring at the same time. Some tasks will yield dependent work products and some tasks won't. The tasks that yield independent work products definitely have to happen in parallel to speed things up, and dependent work products require careful planning. For example, a middleware programmer can build entity classes if the schema is known, but if the DBA is writing stored procedures before finishing the database schema then the entity programmers are stuck waiting.

The key to sustaining optimal inertia is to present alternate tasks when a roadblock on one task occurs. For example, if my schema isn't completely defined then I can write unit tests for coded entities. Sustaining inertia is almost impossible when roles and tasks aren't very well defined.

Keep It Simple Stupid!

Less is more. When it comes to building software, coding every combination of methods you can think of may be fun but these are seldom necessary. Keep the number of public features to a modestly sized list and encourage team members to build to the public features without knowledge of the internal nuts and bolts. If the interface doesn't make it clear, resolve the murky parts by publicly asking the author to modify the code and add comments rather than just explaining it to you. By improving the implementation, everyone benefits.

Insist on Testing

Insist on every technologist testing his or her work product. For programmers, this is easy because we have great tools like NUnit, but every technologist should do the equivalent of proofreading, spell checking, comparing inputs to expected outputs, and so on. If a technologist is writing a technical document, misspelled words, sentence fragments, and run-on sentences are bugs. Fix them. A programmer won't care, but a professional technical writer will (which again supports specialization).

Manage Change Aggressively

A small child knows that, if you stand in one place and spin in circles, you get dizzy and fall down. While simulating a drunken stupor is great fun for a child, running around in circles is not responsible adult behavior. The more you change directions, goals, tasks, features, and schedules, the more you approximate the child spinning in circles and falling down. It is surprising how many projects look just like the small child spinning in circles from 1,000 feet up.

Manage change aggressively because building inertia and maintaining direction are critical to building software quickly and sustaining team mental health. The key here is remembering that software features do change but critical, high-risk features shouldn't change very frequently. So, working on those first will help lock in important milestones, build inertia, and insulate team members from drunken, stuporous spinning.

Your Projects Don't Have to Fail

Software projects don't fail accidentally. They fail because there is a lot of exceptional information out there that is largely ignored. Few—if any—universities currently train people to be programmers, architects, or managers. They train people to write algorithms. Unfortunately, software development is a lot more involved than writing algorithms and avoiding syntax errors.

If people really want to build killer software and do it in affordable units of time, they will have to go to University. University is a metaphor for all of the great information that exists for the price of a book that will teach you how to be a good architect, programmer, or manager.

The adage "measure twice, cut once" applies to software, but (snip, snip, snip) who is doing the measuring?

About the Author

Paul Kimmel is the VB Today columnist for and has written several books on object-oriented programming and .NET. Look for his upcoming books UML DeMystified from McGraw-Hill/Osborne (October 2005) and C# Express from Addison Wesley (Spring 2006). Paul is also the founder and chief architect for Software Conceptions, Inc. founded 1990. He is available to help design and build software worldwide. You may contact him for consulting opportunities or technology questions at





Leave a Comment

Top White Papers and Webcasts



Most Popular Programming Stories

More for Developers

RSS Feeds
