They say "It's tough to make predictions, especially about the future."
When it comes to war strategies wording gets blunter: "No battle plan ever survives contact with the enemy"
Even if it sounds harsh, the consequences are valid, especially when it comes to software development. Even during development there are new specifications, amendments, changes of platforms and much more. We often have to adapt, but sometimes the only help is protection against it.
Followers of flexible methods have come to terms with that and call out: "Embrace Change!" Followers of inflexible methods come up with clever procedures to protect themselves against too much change. Both cases have one thing in common: There is a model that governs software development.
Even at first glance one finds surprising parallels to religion:
- Models provide "Sense" - I too have my place in an often complex interrelationship.
- Models make "Sense" by offering a teleological connection: (In the end) It all has to be good for something.
- Models regularize: "Thou shalt remember the sabbath day, to keep it holy."
- Models "encourage": "Ora et labora"
- Models subdue: "Thou shalt have no other Gods before me."
At the very top of this religion are the high priests - the software bureaucrats. Software bureaucrats don't exercise a productive role in their function. They don't acquire, they don't take part in architecture reviews, they don't program a single line of code, neither do they provide specifications nor test cases - but they ensure that everything happens within an orderly model.
There is nothing to say against this. Many people accept religion and find fulfilment therein. But let's be honest: What is our work about? Creating sense or turnover?
Are we in our line of work academics, who follow principles, or are we pragmatics who sometimes choose different ways? Do we accept principles as pillars of faith or do we proclaim that we're able to judge them? Or the other way round: Do we accept "holy cows" which hinder a regulated life, just because the priests grant them free range?
I want to emphasize again: Any software development (even a flexible one) includes step models and to a certain extent also bureaucracy.
What We Can Learn From Religion
After these admittedly very pointed remarks I want to emphasize: We need step models. We also need "evangelists" who preach them.
In the middle ages churches and convents were important places of culture. Monks knew how to read and write, spoke foreign languages and in many cases were more sophisticated than the common people. The same applied to the priests. A software bureaucrat should ask himself, if he's at a comparably high level.
Typical questions are:
- Do I really know what the other participants in the development process need?
- Or do I only think that I know it, because 20 years ago (which at corresponds to at least 100 IT-years) I had been partaking in a similar process?
The other aspect concerns modernity: Often we shake our head about societies that refuse to develop due to strict religious rules. In software architecture we say that a model is "well" if nothing can be omitted. That is also a point of interest:
- Is the newly developed process slim - can it be further slimmed down?
- Is the newly developed process good or just well meant?
And here shows an important difference between the software designer and the software bureaucrat: A software bureaucrat has to be brave, for he has to be able to admit mistakes and be ready to adapt a bad process.
It's easier for a software developer or a software designer: When you have to justify a bad decision, you point at a book or maybe an SAP-standard, where this very step method is used. In the end you correct the (often self made) mistakes and everything is fine again. If a software bureaucrat doesn't show this courage, he often forces whole departments to use outdated or even harmful step methods.
What Kind of Software Development Process Should We Use?
Most of my time in my career as software developer I had to follow non-agile processes and from my mind I’m believing we need regulation and to a certain limit bureaucracy. Some days before I learnt in a great and very inspiring talk that even in big companies like SAP agile methods like Scrum and XP have been used with success, see “Agile Softwareentwicklung in großen Organisationen - am Beispiel SAP". But what methods shall we use? I admit that I don’t know the answer - but there are some things I believe to be true:
- There is no silver bullet and there is no perfect software development process.
- Every process must fit to the organisation and to the developers.
- And most important: We have to talk honestly about pros and cons of processes – we don’t need any kind of religious fanatism.
I hope I can start a discussion about software development processes: What are your experiences with agile and non-agile methods especially in ABAP development? What do you favour? What are their strengths and weaknesses?
