A grade student was asked to write a short report on Socrates:
“Socrates was a philosopher. He went around telling everyone what they did wrong. They fed him hemlock.”
Vincent Maraia, from The Build Master, ISBN 0-321-33205-9
“If you want to know when your product is going to ship, just ask your Central Build Team or someone close to the daily build… We didn’t use the crazy estimates we got from product or program managers who used a Gantt chart loaded with guesses…”
Ha-yuck, ha-yuck. I always wanted to use the Socrates quote in the context of an otherwise serious piece of work, so I will now set about to connecting the dots between it and the other very funny quote, or VFQs, as they’re known to insiders here at the bureau of Very Funny Quotes.
I have been consuming The Build Masters by Vincent Maraia at an alarming rate, and it’s not hard to figure out why. This is a great read on the internal build process at Microsoft, and the tool support required to make it all happen smoothly. It just so happens that I own the Developer Technology Specialist role in Microsoft Federal, so the content is all the more relevant to me and my customers. And I’m really humble - I mean, I’m truly great at humility.
Years ago, I was on a project, and it was yet another death march. The project was slated for delivery in about 12 months, and 2 months into the debacle everyone on the dev team knew it was a loser. My friend John and I would leave work, and sit on a park bench adjacent the job site, and drown our sorrows by dissecting the ribaldry of the day at work. We decided that if you really want to know software project status, the last place to look was project management. So when I read Vincent’s VFQ, it really struck a chord.
So you say, “Rick – why must this be so! Why can’t we have a better way of knowing the truth about project status?” To which I always respond, “My name’s NOT Rick – it’s Ken.”
Well, I claim that there is a better way, and it includes both human and software tool assets.
Although some folks are dismissive of softer assertions in the Agile Manifesto, like the plank endorsing courage as a key factor for project success, I say that courage, albeit intangible, is a cornerstone of success on software projects. Steve McConnell advocated, a least a mules's age ago, having an anonymous channel for submitting "concerns" to management regarding project status. Obviously, this is tacit acknowledgement of the problems brought on by a fit of courage.
When Vincent makes his claim regarding truth in project management, I believe that he is implicitly referring to several factors. One is the courage requirement, another is the source of deterministic data points that actually provide real insight into project health. And that source is of course, the build process and metrics gathered during its execution. I advise not taking too narrow a view of the scope of the build process, and I would expand it to include tasks like source code check-in, work item tracking, and unit tests.
The success of a software development organization at repeating past success is a function of the weight that the organization gives to the importance of the build process. Properly resourced, and with good automated tool support throughout, metrics can be captured with relatively little friction. It is these metrics that give the outside world a clear sense of the project status. As an aside, allow me to make a shameless plug for Visual Studio Team Foundation here, as this is one of the unique values that this tool provides.
Finally, where does that leave us? Well, I say hire enlightened and courageous practitioners and wise management, and give them proper license to implement a robust build process. Provide resources and great software tools to the build teams, and watch repeatable successes happen. And if you fall short on that enlightenment and courage thing …
“Tell the truth, and then run like hell!”
Anonymous philosopher and track star
Rick... I mean Ken Garove