A couple of days ago, Robert “Uncle Bob” Martin asked Where is the Foreman?:
The foreman on a construction site is the guy who is responsible for making sure all the workers do things right. He’s the guy with the tape-measure that goes around making sure all the walls are placed properly. He’s the guy who examines all the struts, joists, and beams to make sure they are installed correctly, and don’t have any significant defects. He’s the guy who counts the screws in the flooring to make sure it won’t squeak when you walk on it. He’s the guy — the guy who takes responsibility — the guy who makes sure everything is done right.
Where is the foreman on our software projects?
Many moons ago, way before I started making a living writing software, I spent several years in the US Navy as an enlisted man specializing in operating submarine nuclear reactor plants. Freshly out of the training pipeline, I reported aboard my first submarine, which happened to have just started an overhaul at the Pearl Harbor Naval Shipyard. The shipyard had confidently scheduled eleven months for the work, even though the standard for that particular type of overhaul was closer to eighteen months. By the time I reported aboard, the boat was already in drydock and the heavy construction work was well underway. The vast majority of the work was being done, not by the ship’s crew, but by civilian shipyard workers, supervised by shipyard management – including, of course, plenty of foremen. We of the ship’s crew were heavily involved in the quality-assurance role (since we’d be the ones living with the results). In particular, whenever a reactor plant piping system (seawater, fresh water, reactor coolant, etc.) was modified, the resulting work had to be hydrostatically tested and we had to sign off on the test results. These tests generally involved:
- isolating the modified piping from the rest of the system
- connecting a test pump and one or more high-accuracy pressure gauges to the sytemm
- filling the piping with water
- pumping enough additional water into the piping to raise the pressure well above the maximum pressure normally expected in that system
- shutting off the test pump
- and watching the pressure gauges
To pass the test, the system had to hold test pressure for a specific period of time. So, the very first time I was involved in one of these hydrostatic tests, we had all the valves lined up properly, the system was filled with water, and one of the shipyard workers started the pump … and the pressure didn’t go up.
Ooops.
They ran the pump some more, and the pressure still didn’t go up.
Ooops.
It turns out that one of the welded pipe joints hadn’t actually been welded fully. The presence of those above-mentioned shipyard foremen didn’t prevent one particular welder messing up. Neither did any of those foremen spot the problem prior to hydrostatic testing.
Eventually, the leak was found, and fixed, and successfully tested. Eventually, in fact, we got all the systems working again. Eventually, we were able to take our newly-overhauled submarine out to sea and start performing the sorts of missions we were being paid to accomplish.
“Eventually”, however, ended up being twenty-six months after entering the yards. Not the eleven months originally scheduled. Not the eighteen months that the Navy considered “normal” for that sort of overhaul. Twenty-six months, with far too many of those months involving twelve-hour shifts seven days a week trying to “catch up” to an unrealistic schedule slipping into the abyss. (Not that that would sound familiar to anyone in the software development world. </sarcasm>)
And all that happened despite having all those foremen.
So would having foremen in software development solve our problems, as Uncle Bob implies?
If you want to get a project done, done right, and done on time, you need a foreman. And that foreman has to be so technically astute that he can check the work of all the workers. He has to have the authority to reject any work he considers sub-standard. And he also has to have the power to say “No” to the unreasonable demands of the customers and managers.
My answer: nope.
It’d probably be very helpful; don’t get me wrong. In fact, I’d love knowing that a second set of eyes would look at my work, providing a backstop in case I missed something, or giving me glowing feedback about the stuff I got right. I’d love having people on my team with both the skills and the bandwidth to do that sort of review quickly enough that the review process didn’t bottleneck the project as a whole. I’d love knowing that the organization I’m working for values high-quality work enough to assign that sort of person to my projects, not to grind out code, but to keep the standards high.
But having foremen is not sufficient to guarantee project success. I found that out back in the yards, many moons ago.