I am always surprised by the fact that even great developers often do not insist that the organizations they work for purchase the necessary tools that would make them even better and more productive. Debuggers are of course part of everyone’s toolbox but other tools such as memory corruption detectors, source code coverage, and performance profilers go virtually unused. Part of the reason for this is the time crunch that developers constantly face—the last thing they need is yet another learning curve to climb.
The way around this quandary is to designate one team member as the “Tool Smith.” This individual is responsible for learning the innards of each tool within the toolbox and disseminating this knowledge to his or her partners in crime.
If there is anything that developers hate worse than documentation, I have yet to discover it. Most developers would prefer Chinese water torture to writing a document in a natural language. I have, through trial and error, hit on a strategy that I have used with considerable success.
Establish a process that outlines the level and quality of documentation that is required. Make it clear to the team that you do not expect a polished novel or even completely grammatically correct prose. What you want is a brain dump that will be used as input to the documentation assembly line. Develop a standard set of templates that remove formatting issues from being a discretionary consideration. Provide basic training related to screen capture utilities, MS Visio, MS PowerPoint and any other tools required to do the job. Hire professional technical writers to take this raw input and produce a professional deliverable.
By shipping department I mean everything required for getting the actual physical product out the door. This includes tasks such as:
And a host of other vitally important details that need to be tended to. My only recommendation in this space is to hire the youth. Hire really bright young individuals that can get excited about this kind of stuff because they perceive it to be a stepping-stone into the biz. Help them create a working process and then celebrate their contributions.
Technical support in this day and age when it is often difficult to find a human being to talk to when problems arise (and they always do) is an area that should be perceived as an opportunity to derive competitive advantage. Do not staff this function with your weakest players. I am of the opinion that everyone should be required to do time in support. Not only can it be a personally rewarding experience, it is often one of the best inter-personal educational opportunities that exist for the geeks among us.
Factories are judged by the quality of the products that they ship. This is not a monument building exercise. Develop and institute these processes and get on with the business at hand. If you implement the basics described in this chapter you will be ahead of most of your competition and equal to the rest. If you choose to take it to the next level then you are a sick individual and have way to much time or your hands. I would never hire you.
This chapter has focused on factory best practices with respect to software development. Many of these ideas are applicable to other domains wherein soft goods are produced (e.g. the publishing business). You should consider adopting those ideas that you find useful.