Programming or Engineering?

I was reminded that I hadn't posted anything in my field of IT yet...so...

Recently, on a trip to Seattle I had a chance to read Professional Software Development by Steve McConnell. McConnell's name is of course instantly recognizable through his books Code Complete, Rapid Software Development, and the Software Project Survival Guide which I've read previously.

In this book McConnell argues for moving the state of software development from its current state as a craft or art to the more rigorous approach he terms Software Engineering (chapter 4, Softwar Engineering, Not computer Science). In this approach software development is more systematized as developers apply proven techniques and disciplines to their projects. He does this by organizing the book into four parts, The Software Tar Pit, Individual Professionalism, Organizational Professionalism, and Industry Professionalism.

McConnell argues quite persuasivley that many of the techniques and processes ("body of knowledge") needed to deliver software on time and on budget are well known and have been for quite some time. Organizations simply don't take advantage of this body of knowledge and treat software development only as construction or coding. I was particularly struck by McConnell's analysis of the stable core of this body of knowledge and his estimate that as of 2003, 50% of the knowledge needed to develop software is in a state he calls the "stable core" (p41). In other words, the stable core is that knowledge that developers can invest in early in their careers and that doesn't change over time.

All of this leads McConnell to the most controversial aspect of the book; his analysis that software development is progressing towards professional status (chapter 6, Novum Organum) akin to the traditional engineering, medical, and law professions. Those stable and older professions all incorporate professional education, accreditation, individual and/or organizational certification, and licensing. For my part, I'd love to see a more rigorous approach to development, and if that means licensing of some small percentage of developers (McConnell estimates around 5%) then I'm all for it.

One of the most interesting aspects to me is his support for true software engineering degree programs rather than simply Computer Science degrees. He argues that the decrease in CS degrees issued since the mid 1980s (and only now starting to rebound), is related to their lack of relevance to the day to day work of software developers (chapter 18, Hard Knocks). I'll have to admit that I have often thought that my CS degree was ill-preparation for so many of the tasks and skills needed to develop software. I for one, would heartily like to see more software engineering degrees offered that focused not only on code creation but also estimation, design, analysis, testing, documenation, etc. Back in the day when I received my CS degree, nobody even thought there was a difference and so many students had no idea what real world software development even entailed as they set out on their first job. In fact, I distinctly recall after reading Code Complete, that this book should be required reading for every new employee in an organization since it teaches so much that a CS curriculum leaves out.

I also was interested in his classification of organizations as "process-oriented" (NASA or Boeing) or "committment-oriented" (Microsoft). The former emphasizes repeatable processes and standard techniques while the latter looks for developers who "sign up" or commit to a project and just do what it takes to get the job done. The extremes of these two types are referred to as bureaucratic or sweatshops. The former is overly process driven, so much so that developers are bogged down in documents and meetings, while the latter requires long hours and burns people out. In my experience I see alot more organizations following the committment-oriented model for two primary reasons 1) They see how Microsoft has made it succeed, and 2) It is cheaper since they don't pay overtime and requires less initial investment by upper management. The problem however as I see it, is that as an organization grows it becomes more difficult to hire developers who can be so invested, especially as the median age of developers continue to rise (now around 34 years old with the distribution moving to the right end of the curve). And secondly, organizations rarely provide the autonomy (that equals motivation) that Microsoft does to create software. Getting an organization to move from committment to process is incredibly difficult and this is just where many organizations fail. McConnell's inclusion of his company's professional development program (chapter 16) is a breath of fresh air. Would that all organizations took this approach to developers as more than simply a set of programming skills and language profficiency!

In all, I'd highly recommend this book anyone who looks around and sees projects out of control and wonders what could be done.