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 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.
Where is the emergence of specialized roles? Where is the upfront design? Where is the storyboarding of the implementation cycle? Where is the consistent use of patterns and refactoring? Why is everyone still trying to figure out how to build a custom persistence (database) layer? Why are programmers, architects, and analysts expected to all start on the same project on the same day? What are the programmers doing while the architects and analysts are architecting and analyzing? How come the promotion path for technologists is always from technologist to manager when these are two different disciplines?
In this editorial, I will try to answer some of these questions by describing a scenario where software can be designed, programmed, and assembled as quickly and inexpensively as possible. How quickly? Well, you will have to try this approach until the basic tenets become second nature and then tell me.
Prerequisites to Building Software FastThis article is really about the software building process, not necessarily the definition process, but you have to define what you’re building before you can build it quickly. Along that vein, here are the prerequisites to building software as quickly as humanly possible:
- 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.
- Use a macro schedule for the team and a micro schedule for individuals.
- 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 TeamsBuilding anything with a new team carries a huge risk factor. Try to avoid building anything important with a new team. If you have a new team, build something disposable in isolation. This will allow members to learn to work together before they have to succeed.
If the team members play well together, they will work well together. If one or two talented members do not work well with the others, isolate them geographically. Also, always assume that the boss is a dysfunctional team member and move him or her to another floor or building.
When your team does work well together, try to keep them together. People will leave, however, so carefully— but continuously— audition new members for the team. This will prevent a successful team from ever totally dissolving.
Eschew GeneralistsA generalist makes a good spouse, but only a marginal technologist. In a spouse, it is useful to have someone who makes a little money, can cook and clean so you get a break, and is a good parent so the kids get good values from both parents. Among your development team, generalists are less useful.
While having solid general skills is good, working in multiple roles at the same time isn’t as good. The reason is that people are likely to be very good in some areas but marginal in others and they will work in earnest at the things they really like to do. The result is generalists will appear to be average performers instead of superstars because of the moderate to low performance in their areas of lowest interest. In contrast, when a person is permitted to work with undivided attention in an area that is a labor of love, he or she will perform at a much higher level.
Specialization is not an excuse for C# programmers to be ignorant of SQL, for example; it is permission to focus on doing the C# work intently.
Advanced Design Work Is CriticalAdvanced 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.
I am not advocating one-size-fits-all design. Small projects can use a simple outline with an organized statement of work, and big projects will need UML models and other documentation, which might include prototypes. However, a significant amount of this work should be done before the programmers are summoned.
Construct by Risk and ImportanceThe hard and simple fact is that projects often run out of time, money, or both before 100 percent of the original feature set is implemented. An overlooked fact is that in many instances a lot of what is built is fluff. Prioritizing by importance and risk gives your team a very good chance of building the critical subset of features before your project runs out of gas.
An important additional concept here is that if the software looks promising and solves most of the business case then 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 PubliclyMovies are great— a story that one or two minds conceive takes on three-dimensional life in celluloid and entertains thousands or millions of people. How does Hollywood do it? Storyboarding. The scenes, cast, characters, location, and equipment use are all planned using something that approximates to a cartoon strip. The same technique works for software too. Let me explain.
Suppose you want to provide good technical documentation for your next killer app. It would be helpful to coordinate the technical writer’s time around the project’s production schedule. If the writer won’t be needed until the end of the project, why pay for the writer to be sitting around in the meantime? Suppose your best DBA works in another city. Wouldn’t compiling a list of tasks for him to complete during the two days he’s working at your location make sense?
Storyboarding is a good way to allocate resources and manage dependencies. If you are lucky enough to hire a graphics artist for your GUI work, you could create an actual visual storyboard. Besides being cool, it’d be a great way to get team members to notice and pay attention to the schedule. At a minimum, schedule tasks in a very public and visible way.
Define Macro and Micro SchedulesUse a macro schedule of milestones for the team and make a big deal when the team reaches them. Failed projects fail one milestone at a time. It is also important that the team’s milestones are big enough to help foster an atmosphere of excitement and success.
If a milestone is missed, make a big push to complete the milestone and then proceed to the next one. It is better to push to a milestone and then go back to a normal effort level than to promote 100-hour workweeks all the time. A culture of overtime is a terminal disease; the cure is better planning and short bursts of extra work only when needed.
Frequently missed milestones are a function of mismanagement. Better estimating procedures are needed, not longer hours.
For technologists, use micro schedules that are no longer than about a day. Have each technologist estimate his or her own subtasks and then hold him or her to it. New technologists to on new teams using new tools will miss, but experienced technologists on old stable teams with familiar tools will provide good estimates. Reward good estimates and discourage the age-old habit of padding to death.
Discourage the practice of permitting schedules to slide one day at a time. If a little overtime is needed to catch up, so be it. If a technologist is always working late, you need better scheduling, more training, additional helpers, or a combination of all three. This is a function of good management too.
If programmers are rewarded for shorter turnaround times and real improvement over historical performance, you can build a culture of personal improvement.
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.