Where’s the Silver Bullet?  

By David B. Robert

Is there a silver bullet?   Brad J. Cox in his article, “There is a Silver Bullet” maintains that if you view the facts presented in the article “No Silver Bullet” by Frederick P. Brooks, Jr. from a new perspective a more optimistic conclusion emerges in which there is in fact a silver bullet.  The optimism expressed by Brad Cox reminds me of the little optimist in the story of a little optimist and a little pessimist who were twin boys.  Alike in every way but their personality, the boys were steadily driving their mother crazy when she finally sought the help of a psychologist to hopefully balance the two boys out.  The psychologist recommended the mother buy the little pessimist all the finest toys money could provide for his next birthday.  For the little optimist, she was to simply dump a large pile of manure in the center of his bedroom floor.  Well the twins’ birthday finally arrived.  The mother peeked in on the little pessimist first.  She found him sitting in the middle of his room amongst all the shinny new toys with a frown on his face and no appreciation for what he had.  When he saw his mom he said, “I wonder what my brother got?  I know it has got to be better than what I have.”  The mother sadly shook her head at having spared no end on the little pessimist and went to check on his brother.  When she looked in the brother’s room she was surprised to find him on top of the pile of manure digging like a crazy man.  He saw his mother and said with a big smile, “You can’t fool me.  I know where there is manure there has got to be a pony!”  This paper will compare and contrast the views of the two articles with a final focus on what Fred Brooks presents as  “the most important single effort we can mount” to help alleviate the current software predicament. 

Like the boy digging for the pony, Brad Cox is convinced a silver bullet will materialize and save the day for software development.  He envisions “a software industrial revolution based on reusable and interchangeable parts driven by a vast economic force of consumers wielding the behavioral modification tool of antiquity: money.”   Cox’s revolution will culminate with the obsolescence of the professional programmer by making every computer user a programmer.  Brooks on the other hand displays a firmer grasp of the facts with a more straightforward view of how software and the software industry really are.  Brooks points out the complex nature of software, which Cox seems to conveniently ignore.  Cox would have all of us stopping at a plumbing supply house where we could pick out the various items needed to complete our project.  Once we got home all the parts could then be easily assembled into the perfect product.  Yet, Brooks notes that software products are intrinsically different from one to another.  Canned products may satisfy a few, but with software’s ability to be changed and to conform to the desires of the user the creative possibilities are infinitely larger than what canned products will ever be able to deliver.

Brooks recognizes and acknowledges the strengths and the weakness of what exists.  He concludes his article with a solution that, while being no silver bullet, does offer a lot of promise.  And that is the great designer.  Cox would have every computer user as his own great designer when finally given access to the right parts store.  Stepstone Corp. is his attempt at providing that store.  Yet there is no horde beating a path to his door.  After seventeen years and counting it does not appear Stepstone will produce a silver bullet or a pony.

I think the most important single effort we can mount is to develop ways to grow great designers.

Frederick P. Brooks, Jr 

 So what can we do to grow great designers?  Brooks offered several suggestions.

1.  “My first proposal is that each software organization must determine and proclaim that great designers are as important to its success as great managers are.”

2.  “Systematically identify top designers as early as possible.  The best are often not the most experienced.”

3.  “Assign a career mentor to be responsible for the development of the prospect, and carefully keep a career file.”

4.  “Devise and maintain a career-development plan for each prospect, including carefully selected apprenticeships with top designers…”

5.  Finally, “Provide opportunities for growing designers to interact with and stimulate each other.”

Cox referred to his silver bullet as a paradigm shift in the culture. While not being a silver bullet, I believe there is a tried and true paradigm that can provide a means to grow great designers along the lines of what Fred Brooks has envisioned.   In software engineering communication is stressed as an important ingredient to the outcome of any project.  Communication is also stressed in military aviation as an important ingredient to the successful outcome of any mission.  A story is told about two Mohawk pilots scheduled for an early morning mission that demonstrates the drastic effects possible when communication breaks down.  One of the pilots obviously appeared to have awakened on the wrong side of the bed.  So the other pilot was silent throughout their whole preflight routine except for communication germane to the job.  During the takeoff roll the pilot that was feeling all right finally decided to say something to the pilot that was down in the dumps.  He said, “Come on Joe, cheer up.”  Joe said, “Roger, gear up.” as he hit the lever that raised the gear.  An expensive aircraft bellied in due to the poor timing of the misunderstood remark.  For economic reasons the majority of civilian helicopter missions are solo-pilot endeavors where the military trained pilot is considered to have the superior training and overall ability as a pilot.  The military trained pilot did not accumulate all of his superior experience in a solo environment.  Herein lies the paradigm that can be followed to help produce great designers.  

Fred Brooks continues his comment #4 above with, “…episodes of advanced formal education, and short courses, all interspersed with solo-design and technical leadership assignments.”  The focus here is solo.  Programming as it exists today is primarily a solo endeavor.  Sure software teams meet and collaborate on software projects.  But when it comes time to do the coding that makes the end product come alive each team member does their part in solo alone at their own individual workstation.  Fred Brooks even mentions the “individual workstation” in his article.  For practical and economic reasons programming has always been a solo endeavor at individual workstations.  However, for practical and economic reasons the concept of the dual workstation modeled after the military aviation paradigm can advance all of Fred Brooks’s suggestions in growing great designers. 

Duties are divided and shared in an aircraft.  One pilot manipulates the controls while the other pilot navigates.  Generally, there is a pilot in command (PIC) and a co-pilot.  The PIC is ultimately responsible for the successful outcome of the mission, however the co-pilot is almost always an important asset.  The duties, but not the overall responsibility, are switched around.  The PIC orchestrates who does what.  He may manipulate the controls while letting the co-pilot gain valuable experience navigating, however when navigation becomes more critical such as in the vicinity of a demilitarized zone or a prohibited area the co-pilot may find himself at the controls while the PIC assumes the navigational duties.  The co-pilot is there to assist, and is usually but not always the less experienced pilot.  The co-pilot is supervised by a skilled mentor and has the benefit of being able to observe this mentor work.  By modeling the skills he sees, a co-pilot is often able to quickly move into the role of the skilled mentor.  Even where turnover is high, as in one-year duty stations, there is a smooth transition from the inexperienced becoming the experienced that now leads others less experienced into the skills and mastery he now enjoys.    

Likewise, with a dual workstation, duties can be divided and shared.  Crucial programming and documentation can be done simultaneously.  If necessary the documenter can pause to look something up that is crucial to an important piece of code.  If the programmer in charge completes a critical piece of code that needs replicating, he can pass the code replicating process to his assistant while he puts some icing on a particular piece of the documentation.  If one of the programmers is well versed with some necessary esoteric construct of the language in use, he can share this knowledge with the other programmer thus bringing him up to speed in a way that no digging through a book could ever do.  Both programmers can code different elements at the same time if the programmer in charge feels that is the current best utilization of their time. 

I believe the concept of the dual workstation modeled after the military aviation paradigm has the ability to advance programmer skills rapidly and thus production tremendously.   It will provide an easy means to systematically identify top designers as early as possible.  The programmer in charge will have first hand exposure to the skills and abilities of the other programmer.  Every programmer in charge in the company will have a mentoring role where each offers a different flavor and style to the other programmers as they get exposure working with different people and more skills for their programming tool box.  This concept provides a built in effective apprenticeship with top designers and programmers for the new less experienced programmers.  One visit to a military club where aviators mix and mingle and share the details of the day’s events will reveal that their work environment itself provides the catalyst for opportunities to interact with and stimulate each other in relation to the nature of their work.  

If a software organization is serious about growing the “Great Designer”, the dual workstation method should be given serious consideration and explored.  At first glance by the uninitiated the dual workstation may seem like a waste of resources and economically unfeasible.  However, it is possible to implement dual workstations on a small scale only where their numbers are increased only after their worth is proven.  There will always be room for productive work in solo at individual workstations, but the dual workstation experienced programmer, whether working at an individual workstation or a dual workstation, will quickly standout as a cut above those who have not tasted its benefits.  There is no silver bullet. But, we can develop ways to grow great designers, and implementing the dual workstation environment will be an important step toward furthering that goal.