Afew weeks ago I returned from holiday to find a lot of postings on the accu-general mailing list that had been initiated by my last editorial. The thing that started them was a posting by Allan Kelly (which also appears as a "letter to the editor(s)" in this issue). The thing that struck me about the discussion was that it generalised rapidly from the evolution of Overload to the evolution of software development as a profession.
Software development as a profession
Is software development a profession? Clearly, many contributors to the mailing list feel that it should be - they bemoan the lack of accreditation that is available to architects, doctors, accountants, and so on. Some of them even proposed that the ACCU might fulfil this role! (In the UK there is an organisation better constituted to do this - the BCS - but it lacks the recognition and authority that would be needed.)
How does a profession come to be? It requires several things: for the professional it requires there to be a strong incentive to be recognised as a professional (this could be legal, financial, or access to market). For the client, a strong incentive to employ a professional (this could be legal, guarantee of quality, or access to market). Is this what we see in software development?
At the weekend I was talking to a friend of mine from university, he works in software development and is a qualified project manager. To me this was a novelty - most of the project managers I've worked with have no qualification and, indeed, don't seem to have ever opened a book on the subject. (Mostly they have attained the role because that is what you do after enough years as an analyst-programmer, business analyst, or whatever.) It seems that his qualification (Prince 2) has some market value - there are organisations that require it, but hasn't been enough to keep him in employment recently. It is also hard to assess for those not familiar with it: it relates to a particular method which may or may not be suitable for a specific project.
The situation is worse for developers - what recognition do developers get for having enough interest in what they are doing to open a book? There are qualifications in particular technologies - but these are often short-lived and don't always reflect a developer's primary skill: that of solving problems. This isn't just a problem for the developer, but also for the prospective employer: how are they to identify the useful candidates?
This last question has vexed me somewhat over the last couple of weeks - I've been doing technical assessments of candidates for a client. Before I see candidates their CVs have been reviewed and the best selected, followed by eliminating those that get poor scores on BrainBench - but despite this selection process the majority are clearly unsuitable. (For example, when presented with a class hierarchy that makes use of the implementation of "cat" by specialising it to produce "dog" they approve of this approach to the reuse of code.)
But it is not typical of the job market for an employer to care about such fine distinctions between developers - despite my misgivings about their abilities almost all of these developers are in work and have succeeded in a series of jobs. Typically they assume they have done well enough on the test - displaying a confidence in their abilities, which appears to reflect that they are able to deliver what their employers expect of them.
To me it is clear that the majority of developers and the majority of their employers neither recognise nor care about the qualities that have been represented as "professional" in the ACCU. And yet these businesses are commercially viable - they are not being outcompeted by a few more discerning organisations. It would appear that, for the business that employs them, there is no commercial value to professionalism in software development staff.
To me this is something of a paradox: I have repeatedly demonstrated ways to reduce the cost and timescale of software development. The size of the savings can be considerable - in one organisation a cost overrun of 120% was typical (and a significant part of the turnover), reducing this to 15% was not recognised and the "traditional" approach has been reinstated. (The other difference, which affected developers more than business costs, was a similar reduction in unpaid overtime.) Professionalism in software development does save time and money - it can be demonstrated; it is repeatedly reported in books and journals; and, it is rarely practised.
Where does this leave software development? Clearly, it doesn't meet the conditions I outlined above as being necessary for development as a profession. It isn't a profession now and it won't be in the foreseeable future.
Does this mean that there is no point in being "professional" in the way we approach it? I hope not: the habit of doing things right is a part of who I am - and I have enough experience of the pain that doing things wrong engenders to want to avoid it. I know that a lot of you feel likewise - the ACCU seems to have attracted developers who care about what they do. But, despite the ambitions of some, it isn't a profession.
Software development as a craft
Is software development a craft? In many ways this seems a much more appropriate analogy. The degree to which it relies on the practice of good judgement, and the extent to which this relies on experience is suggestive of this. There are often different "schools" within a craft and the variations between different development methods and tools fits well, as does the importance of the teachings of various masters. (Clearly the masters are those who are sought out for this purpose, not those who appoint themselves.)
The existence of several schools of software development is clear: there are "heavyweight" methods (like RUP); there are lightweight methods (like Crystal); there are weakly typed languages (like SmallTalk); and, there are strongly typed languages (like Java). Some proponents of each of these tend to believe that they alone have seen the one true way - while more measured observation will show that each has both successes and failures. (The existence of several schools isn't incompatible with being a profession - but it does make agreeing the criteria for any professional qualification more difficult.)
What is missing from "software development as a craft" is a recognised system of apprenticeships, journeymen and masters. Very few organisations consider that "I studied with Angelica Langer" is a better qualification than "I glanced at a book once" - and neither, judging by the CVs I see, do developers. (In case you are wondering I chose the example because there is at least one organisation that looks for this specific qualification - they know who they are.)
Does this mean that there is no point in seeking out the masters to learn from them? Again, I hope not: there is far too much to learn for trial and error to be an effective approach (especially when it is often hard to be sure which factors affect the result). The ACCU contributes here by providing several forums in which the masters can be sought: mailing lists, journals and conferences.
Software development as a science
Is software development a science? It is tempting to think that the existence of "computer science" courses provides some basis for this - but the true sciences (mathematics, physics, etc.) don't have "science" in their name. And a closer examination of "Computer Science" shows it to be mostly technology (there is some applied science - mostly mathematics).
The essence of science is the ability to devise experiments to test theories (at least that is how Popper and I see it). And in software development this is singularly hard to do. There is too much uncontrolled variability - and it isn't clear which variables are important. There are people trying to make a science of it: Alastair Cockburn collects anecdotal evidence about projects and tries to identify common factors - but this work is still at a stage where there is a lot of "interpretation" which may not sufficiently repeatable to support experimentation.
One day there may be a science of software development, but as far as I can tell it is a long way off.
Software development as a team activity
One classification I had not considered until recently is the idea that the important classification of software development is that it is a form of teamworking. This certainly fits with my often repeated plea for communication over documentation. And (as I discovered recently when reading an unpublished thesis on the subject - I hope to bring you some of this material in the future) there are various established classifications of team behaviour and development that are very useful in assessing development projects.
Oddly, this had not occurred to me as a useful classification despite its use in one of the first discussions I ever read on development processes (The Mythical Man Month). This uses analogies to teams in several different fields of endeavour to establish the roles and interactions that have proven successful.
On reflection though I think this is the right answer: looking back over various projects I find a strong correlation between the quality of the team (rather than of the individuals) and the results of the project. (The only exceptions I can think of are where a good team failed - and I would ascribe the failure to external factors.)
Software development and Overload
The remit of the ACCU has drifted over the years, it started with a very narrow focus on C as the "C Users Group (UK)". It has expanded into other languages (Overload was originally the journal of the Borland C++ User Group) and other areas of development.
Overload has always been more focussed on the "front line" rather than on the "supply lines" - which has its risks as well as its benefits. There is clearly interest in software development as a professional activity, as a craft, as a team activity and as an organisational function. These interests are not always compatible, but we can try to cover them all.
What appears in Overload is very dependent upon what is submitted for publication, and this covers an increasing range of topics. But there is a commitment from the team of readers to ensure that every article is as good as we can make it. You can do your part by submitting great material - or just by encouraging the authors of things you like.
It is up to you.
