Three perspectives on better software

The agile perspective

When the agile manifesto was published a decade ago I welcomed it. I had been building applications for a decade pretty much according to the principles in the manifesto. During this period I had watched in horror as RUP quickly became a de-facto standard. It was such a derailment of the agile ideas that had started to get momentum in the early nineties. For me the agile manifesto was primarily a wake-up call to developers to get them back to the roots of how you build software systems in an optimal way.
Ten years later the manifesto has come under a lot of criticism. Some people are saying that it is introvert and not customer oriented enough. I find this criticism misguided for two reasons. First of all, I can not see anything wrong in trying to become better at what you do. If a carpenter focuses on mastering his trade and continually improving his carpenter skills, that is a good thing. You would not tell him that he is failing because the houses he builds are not the ones an ideal society needs. A carpenter builds the houses that he is commissioned to build. The second reason I object to the criticism of the manifesto is that it often seems to be based on the assumption that the battle for good software development practices is already won. If real life, it is all too common to find developers hacking away with something that can best be described as crapmanship.

The customer perspective

But still, even if one accepts that the agile manifesto was focused on a better way of building software the question of how to actually deliver something valuable remains. Once you start looking at software from a customers point of view a whole new world of problems and possible solutions appear. A core insight is that even the word customer is a misnomer. You typically have a myriad of stake holders with different and often conflicting demands. The notion of what is “correct” becomes a political issue, something that is at odds with the mindset of most programmers. A second insight is that what users tell you they want is often not what they need. You have to combine knowledge gained from talking with people with observations of how they actually work. Once you are familiar with this customer oriented perspective on software you might come to the conclusion that this is the end of the road. What can be better than building systems in an optimal way and at the same time guaranteeing that what is built is satisfying the needs of at least the most important stake holders?

The systems thinking perspective

Well, there is something better. As long as the perspective is founded on seeing IT as the “solution” your view of the world is going to be absurdly biased. It becomes a case of “If you only have a hammer…”. If you instead start by looking at the organization as a whole and from there work out ways of improving it, you will be able to come up with radically different solutions. Demand for software “solutions” becomes a side effect instead of the main point. Systems thinking is in it’s essence surprisingly simple; study the organization as a whole and help it perform better based on that knowledge. When you start studying organizations in this way you soon realize that some things stake holders place value on are in fact detrimental to the organization. Optimization of parts does not correlate very well with what is good for the whole.
A cynic might note that what I am talking about has a different name, it is called management consulting. Unfortunately, a lot of management consulting is not about studying an organization and finding improvements, rather it is about implementing new ideas in a top down manner.

Unautomating workflow

The difference in perspective between systems thinking and an IT centric view of the world becomes very apparent when you look at workflow. When IT consultants try to improve a business that is built around workflow they will often start by modelling these workflows and slimming them down to their essentials. The ideal workflow is implicitly a very deterministic affair with a sequence of steps and branches that ultimately lead to a correct result. It practice these workflow systems very seldom work as intended and are often hated by the people that are forced to use them.
To see why, first consider the difference between the way agile teams want to work and workflow systems. In agile we espouse things such as self organizing teams and continuous learning. A workflow system is everything but self organizing and is usually not amenable to any real change by the people using it. Do we build these systems because we secretly hope that our users will be as deterministic as our computers?
A systems thinking perspective would look at the whole workflow from the customer’s viewpoint. What can the organization do in order to solve the customers problem as quickly and reliably as possible? Sometimes the solution is changing things in such a way as to reduce the possibility that the customer experiences the problem to begin with. In other cases it might be a radical redesign of the organization such that the front line employee can solve the customer’s problem without handing it over to others. This can be achieved by allowing the front line employee to pull resources when needed.
All of this might sound idealistic and oversimplified. But systems thinking has been used to great effect by a number of organizations and the gains they are experiencing are often dramatic.

Each perspective is valuable

The point I have tried to make here is not that systems thinking is in some way superior to agile. The point is that they solve different problems. Agile is about the optimal execution of software development. Systems thinking is about the big picture and finding the optimal way an organization should achieve its goals. Between these two perspectives is the customer oriented view of software. This is invaluable as a way of ensuring that an agile project achieves the goals that systems thinking has identified.

Posted on 2010.12.13 at 20:48

Comments are off for this post.