I think the article was a little constrained by the 2 page limit. I can appreciate the authors retrospective view on his projects and how he might therefore conclude that control does nothing to improve outcomes. However I think any engineer, scientist or mechanic (etc) could make the same statement and provide equally loose examples and essentially re-produce the same article – hence I do not think it is a software engineering only phenomenon.
When Tom discusses control with respect to project A and project B, the success of Wikipedia is used as an example. I would not classify Wikipedia as a software engineering project. Wiki’s – maybe, Wikipedia – no, I would alternatively classify Wikipedia as a social phenomenon.
There is also I believe a significant difference between control and measuring. I can measure many things, some of which I can control, others I can not control.
How do you measure the success of software?
As stated by Tom, the important goal of any software is
… transformation, creating software that changes the world or that transforms a company or how it does business.
With this goal statement in mind, I think the subtext of Tom’s article is that measuring the act of software creation (i.e. schedule, test cases, bug count etc) does not directly steer the final software product towards satisfying this goal statement. I certainly agree with this idea. Joel Spolsky’s article about the unconventional approach followed by the development team while developing StackoverFlow discusses this very idea; that great software (StackoverFlow) can be produced with little to no software engineering project control. Combining the evidence from Joel’s article with the successful projects identified within Tom’s article might lead the reader to assume therefore that project control has no bearing on the success of software projects? Such a theory is certainly controversial, hence the wide array of responses from the software industry to Tom’s IEEE article. At this point; the community typically fork into two camps:
- Camp A: No project level control is required and instead the craftsmanship ability of the development team will make or break the software project.
- Camp B: Believe any software that is substantial needs a large team (20+) and with such a large team project control is essential.
Is Project Control Optional?
Which camp is right? Both – as they both sit (in my mind) at the two extremes of team size – small and large. Chapter 1 of Microsoft Secrets discusses Microsoft’s challenges with software quality in the late 1980’s and how their original approach of placing a bunch of clever people together and assuming they will work it out had to be watered down with some bureaucratic controls brought directly into Microsoft by Mike Maples from his IBM experiences.
I won’t go into all the types of controls used by the camp B people, as these are well known by many in the software industry. With regards to craftsmanship, I think great technical skill is certainly a major component, however equally important is that the hearts and minds of the developers be invested in the outcomes of the software project that they are undertaking. When you have a small team (<20) of smart people (all craftsman) who want to be a part of the project and also share in any successes or failures, then real magic can happen and project control is simply not needed.
