Custom Enterprise Development Different From Commercial Software?
During a conversation with a colleague at BearingPoint, something occurred to me which I expect is already well-understood by most of my peers: the practice of custom enterprise software development is qualitatively different than developing commercial software. By that I don’t just mean the customers are different, or the resultant tools do different things, but the risks, challenges, and economics differ substantially. In particular, the workforce quality economics are significantly different.
I had this article in my unpublished queue for a couple weeks, and have only now come back to it. I read Bill’s piece on the development skills continuum, which reminded me of the epiphany I describe in this post.
One of Bill’s assertions is:
a successful company could be formed merely by avoiding the above groups [mediocre devs] and only allowing in good developers (or better)
I have long held this opinion as well. However, my work on federal government IT projects at BearingPoint has brought about an epiphany of sorts, which leads me to question this belief.
I acknowledge that an operating system, a search engine, even an office productivity suite or a web browser, cannot be reliably and efficiently developed by the mediocre half of Bill’s skill continuum, the ‘detrimenal’ and ‘useless’ classes. The nature of the work is substantively a technical challenge, which must be met by technically competent people (‘pluggers’ at minimum, with at least some ‘good’ or ‘heroic’ devs thrown in for force multiplication).
However, the custom IT development work which I’ve been engaged in for the last couple of years it unlike operating system development, search engine development, or productivity suite development. The technologies are usually well-understood, the specifications seldom present significant technical challenges, and the quality of the resulting system is less important (although not totally irrelevant; an ususable system might still be refused).
My conclusion after working on a typical IT project with a team that spans almost the entire skill continuum (I don’t think we had any heroes) is that ‘good’ developers can do work alot faster and much better than ‘pluggers’, as would be expected. However, given strong manager and a realistic schedule (that is, one that reflects the weakness of one’s team), pluggers are only slightly less likely to product an acceptable system.
I attribute this conclusion (albeit empirical and qualitative) to a few observations:
- The clients for whom these IT projects are performed usually lack the sophistication required to discern between ‘plugger’ and ‘good’ work products. While I suspect a client might favor the work of a ‘good’ team when compared side-by-side with the ‘plugger’ output, the client is nonetheless unlikely to refuse the ‘plugger’ deliverable because the code stinks, test coverage is practically negative, and it takes two days to set up a machine capable of building it (quality issues may drag down the ‘plugger’ deliverable, but you’d be amazed at the high shit tolerance in large IT projects).
- Non-technical risks dominate the technical ones, reducing net project impact a ‘good’ dev can make. Wishful schedules, missing, ambiguous, and constantly changing requirements, client-side political wrangling, and dependencies on other teams present significant risks which even a ‘heroic’ dev would be hard-pressed to eliminate.
- IT and large consulting firms tend to be staffed by ‘plugger’s and ‘useless’ devs (not surprising considering the likely statistical distribution of tech skills among likely candidates). Thus, their culture and processes are designed for (and probably by) such skill groups. This further impairs the ability of ‘good’ and ‘heroic’ devs to leverage their superior abilities. This can manifest in a number of ways, such as:
- Inadequate equipment and tools, selected by PHBs, bean-counters, and cable monkeys
- Minimal incentive and stimulation to achieve
- Work assignments typically lacking the challenge which intelligent minds require for stimulation and maximal performance
- The client environment is frequently plagued by ‘bullshit’ constraints, which cause frustration, disillusionment, and cynicism among technical minds inclined to roam a bit more freely
All that said, I’ve spent alot of my career in commercial software development, and I can’t say any of the above factors are completely absent. I do feel, however, that they are less pronounced, and the economic value of the technical endeavor is higher, leading to a higher probability that a ‘good’ or ‘heroic’ dev is the difference between likely success and likely failure.
I wonder what it’s like to work at Google…