Tom Gilb proposed a definition of software engineering as “Software engineering is the discipline of making software systems deliver the required value to all stakeholders.” This is a seductive definition but when we start to unpick it, we run into problems.
1. Organisations are incredibly diverse. There will inevitably be conflicts and you probably won’t discover most of them until you deliver a system. Furthermore, organisations change – the ‘value’ of a system is not the same on deployment as when it was initially proposed.
2. Many systems are deliberately disruptive. Management want to change ways of working and do so by introducing new software (often ERP systems). The idea is not to deliver value to all stakeholders but to deliver value to the ‘organisation as a whole’ – whatever that is.
3. In some organisations, stakeholders work in a state of creative tension – e.g. doctors and managers in a hospital. As a matter of principle, they will not agree on value.
4. In my experience, getting key stakeholders to engage in discussions about new systems is really hard – they are far too busy doing their jobs. On the other hand, they complain a lot when a system doesn’t do what they want.
Tom’s definition is good because it recognises that simplistic notions of ‘success’ don’t or shouldn’t apply to complex software. But culture and politics and normal human cussedness mean that it’s really hard to make it work.
There seem to be a significant number of people in the software engineering community, especially in the US, who believe that a ‘body of knowledge’ for software engineers can be (a) defined (b) agreed and (c) made a requirement for licensing. IMHO, they have really got this wrong:
1. Bodies of knowledge reflect the past not the future. Generally, it is greybeards who get involved in such things because young folks are just getting on with their work/life, etc. BOK’s reflect what these greybeards know and often they don’t know or understand recent important developments. I know – I’m an oldster too – and all the time I have to actively work to stay open-minded about new developments rather than falling back on what I might think of as ‘fundamentals’ but which may be no such thing. Us 60’s folk have to remember one of our heros, Bob Dylan – “don’t criticise what you can’t understand”.
2. There is a truly immense diversity in software engineering and an engineer developing mission critical software for a spacecraft really has very little in common with a developer tailoring SAP systems for an enterprise. The BOK for the former includes lots of hardware stuff, safety, etc; the BOK for the latter, lots of stuff about business and business processes. Really, let’s not kid ourselves that there is some ‘fundamental core’ that is of practical value to both of these types of software engineer.
My SE book reflects my experience and interests in SE – but I would never claim this was some kind of universal body of knowledge.
J.L. Eveleens and C. Verhoef, IEEE Software, 27 (1), Jan-Feb 2010
This is an article that analyses the frequently cited Standish reports that state how many SE projects have failed and generally present software engineering to be in a bad state. The paper shows that Standish’s method is completely unreliable and the Standish figures simply have no credence at all. I’ve always maintained we’re not that bad at software engineering.
A. Engelfreit, IEEE Software, 27 (1), Jan-Feb 2010
A good discussion of the issues in open source licensing. It provides practical advice on the factors to be considered when using and developing open source software.