The book ‘Making Software*,’ subtitled ‘What really works and why we believe it’ had me drooling with anticipation while waiting for my review copy. I was eagerly mulling over a few questions that I would like to see answered such as what is better, open source or proprietary development and what programming languages are best.
Making Software (MS) is a huge book, nearly 600 pages, although somewhat padded out with references. MS has multiple authors, most from Academia and a few from Microsoft. The result is a lack of an overall theme. In the preface the chapters are referred to as ‘essays’ and indeed, MS contains equal measures of editorializing and research.
Behind the question ‘what really works’ is a widely held perception that software development often doesn’t work—or at least not very well. Tales abound of poorly managed developments especially in government. A chapter on Systematic Reviews debunks this viewpoint—in particular the Standish Group’s ‘Chaos Report’ that claimed to find ‘huge project overruns.’ Apparently Standish Group ‘deliberately solicited’ failure stories—thus ‘one of the most frequently cited papers on project overruns cannot be trusted.’
As an older programmer whose skills were honed on Fortran and Visual Basic I confess a certain unease with modern ‘object oriented’ languages. One of my questions was, ‘Is OO good for productivity?’ Here I was disappointed. MS only provides a 20 page paper on language comparisons and there is no mention of Fortran, SQL, Mathcad, let alone Cobol. Lutz Prechelt’s (Berlin University) comparison of web development productivity covers Perl, PHP and Java to conclude that Java came out both top and bottom (different teams working on the same problem). While PHP is good ‘for small programs,’ it is ‘more important to have the right programmer than the right language!’ I guess anyone could have told you that.
I was still interested to see if anyone else had the same trouble as I did with ‘modern’ languages. The chapter on API usability by Microsoft’s Steven Clarke had eight experienced VB6 programmers tackling the .NET paradigm shift—exactly where I came unstuck! None could complete a simple task in the allotted time—which Microsoft described as ‘a complete bust.’ Video tapes showed programmers scratching heads over the System.IO namespace. This led to a new field of ‘cognitive dimensions,’ an approach to ‘analyze and better understand’ such difficulties. In the end a new class was created to make the programmers’ lives easier. If you are struggling with .NET arcana though, you are unlikely to get Microsoft to rewrite the API for you. Apparently ‘When [Microsoft] started looking at API usability we didn’t know how to do it or if the effort would be worthwhile.’ Microsoft is seemingly a convert to usability now—but why was there ever a doubt?
Another of my questions was ‘Is the open programming paradigm that has given us Linux and a multitude of other applications better than the closed proprietary development of Microsoft et al.?’ This question is addressed in the chapter Quality Wars: Open Source vs. Proprietary Software by Diomidis Spinellis (Athens University) whose work was part funded by EU 6th Framework. Spinellis scored the different operating systems on a variety of quality metrics to find that OpenSolaris has the highest balance between positive and negative marks while Microsoft’s Windows Research Kernel has the largest number of negative marks and Linux, the second highest number of positive marks. ‘The most we can [conclude] is that OS does not produce software of markedly higher quality than proprietary software.’ This is a pretty interesting conclusion in so far as the quality of Linux, developed by a team of enthusiasts, is ‘not markedly higher’ (i.e. it is a bit better!) than that produced by the largest software company in the world, which has of course access to every line of Linux code in existence!
My final question was, ‘how is the programming world shaping up for multi core and clusters,’ a key topic for the seismic processing community. MS is silent on the subject. There is no indication as to what might make multi core or parallel software development ‘really work.’
A chapter on ‘why is it so hard to learn to program’ by Mark Guzdial of the Georgia Institute of Technology riffs on about poor pass rates in computing courses to conclude that computing education research is a ‘fledgling field’ (really, I took a course in 1970—that is one heck of a long fledge!), that students struggle to learn computing, and that we need more tools to measure their progress. No suggestion here that the objects and obscurantism has made learning programming harder!
Dewayne Perry (University of Texas at Austin) studied a million plus lines of C to ask ‘where do bugs come from?’ This is one of longest chapters in the book—but it is frustratingly inconclusive. The authors liken the design of their empirical study to the act of coding itself. It is impossible to create a ‘bug free’ study. I would extend the analogy a bit further—locating a concise conclusion from Perry’s study is like finding a bug in code too. There is one interesting, if rather obvious finding. It emerges that ‘problems with requirements, design and coding account for 34% of the total bugs.’ Thus the ‘fastest way to product improvement is to hire domain specialists.’ This is because ‘lack of domain knowledge dominates the underlying causes of bugs—so hire knowledgeable people.’ A more contentious conclusion is that ‘few bugs would have been solved by ‘using a better programming language [than C].’
As an old fart I would summarize the situation as follows. Today’s programming languages address concerns that are far removed from those of business users. Programmers have turned themselves into an elite breed of experts with arcane knowledge of .. programming. This has disenfranchised domain specialists. Back in 1970, a scientist buddy of mine boasted of learning (Fortran) in a single night. Today it might take you a night to get to grips with a simple ‘Hello World’ app—if you are a fast learner.
* Edited by Andy Oram and Greg Wilson. O’Reilly, 2010. ISBN 9780596808327—www.oilit.com/links/1011_16.
© Oil IT Journal - all rights reserved.