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.