Your Guide to Fast, Fail-Proof Software Development
Massive Parallelism is PossibleMassive 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 then 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 TestingInsist 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 AggressivelyA 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 FailSoftware 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 Amazon.com University. Amazon.com 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 www.codeguru.com 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 firstname.lastname@example.org.
If you are interested in joining or sponsoring a .NET Users Group, check out www.glugnet.org.
Copyright © 2005 by Paul T. Kimmel. All Rights Reserved.
Page 2 of 2