The common path is this:
- Some programmer has to solve a problem. The problem is very specific and he tries to tackle it using the tools at hand and the methods all his peers used successfully until then.
- The existing tools and methods prove to be of no help. Even worse, they start to stand in the way.
- Our programmer is a smart cookie and imagines new ways that solve his particular problem.
- He uses it or at least he tries, but he collides with the established processes, methods or tools.
- All hell breaks lose and the “old ways” fight back. Management is not very fond of new risky ways.
- Since there is no other solution, the freshly found “new way” is masked under some “old” clothes and it is used.
- But the shiny gem cannot be fully covered by dirt. The success becomes known to other people who become interested. Our programmer has now supporters. People start to spread the good news. The “new way” starts to be known in small circles as the “true way”. Our programmer is encouraged to write a book. A bible is born!
- More and more people hear about the underground “true way”. Some bother to try understand it and the context which lead to its creation. Some manage to generalize it and apply it in new contexts. Some reject it because it is not familiar. Some reject it because it does not apply in their context.
- The change wave is now strong. Most people start to hear about the “new true way”. It sounds good. People start to see the daily problems they have with the “old ways” in a new light. Wishful thinking makes them see all solutions coming from the “new way”, the “true way”. Nobody knows anymore where and how the “true way” was born. Our programmer might decide to cash in on the new found celebrity or he might get scared and start to fight the madness. If he does that he becomes a fallen prophet. The “true way” is the deity, our programmer only the messenger.
- The “true way” is adopted as the “only way”. Manuals are written. Processes are created. People are trained and certified. The “only way” is enforced in some places with an iron fist. It starts to look bad if you don’t use it for all your problems. People still using “old ways” are seen like dinosaurs. A dogma was born!
- Some other programmer tries to solve a new very specific problem. He tries to tackle it using the tools at hand…
Dogma (plural is either dogmata or dogmas) is the established belief or doctrine held by a religion, ideology or any kind of organization, thought to be authoritative and not to be disputed, doubted or diverged from.
How often do you see this pattern of dogma creation in software development? More often than you think. How to recognize a newly born dogma? Every time when you have to do something that doesn’t make sense, only to satisfy some principle of X where X is a popular and established way of doing things, you just discovered that X is a dogma.
Let’s see a list of practices that are applied unfortunately most of the time as dogmata even if they certainly have value in specific contexts. Keep in mind that I am describing dogmatic applications of the concepts I am listing.
1. Agile software development
Agile ain’t agile no more when adopted as the official enterprise software development process. The problem with agile is “agile != flexible”.
Agile was born in the world of contractors who have to show something for the money at every status meeting. For a while clients let themselves fooled with use cases written on many hundreds of pages but this doesn’t work no more. They smartened up and demanded to see something working, for a change. Agile came in handy because it allows to show a prototype early on. As long as you keep adding features to it and you are able to demo them there is a good chance your contract will be extended.
While in theory the Agile methodologies tell you to be flexible, the cruel reality is that most people that apply them don’t think a lot before taking the manual and enforcing every bullet point with a thick stick.
There are lots of things that can go horribly wrong when forcing agile in the wrong context. Let’s pick on two:
- Short development cycles or scrum at every phase of a project
The problem here is that sometimes it is impossible to have a short development cycle and demo features at the end of it. You cannot demo a car engine until it is fully built. It works for projects that have a shallow infrastructure and lots of small features. It doesn’t work at all for projects where the infrastructure is 90% of the effort.
- Pair programming
I had two successful experiences with pair programming many years ago. In both situations it worked well because me and my pair had matching personalities, we were actually good friends, the problems were well defined and we didn’t routinely program in pairs for very long periods of time. Twist any of these conditions and you may end up with people killing each other with the keyboards.
Point to take home: not all projects and not all phases of a project are suited for Agile. For another opinion about Agile as dogma read here.
2. Test driven development
TDD has a noble goal but, as we all know, the road to hell is paved with those. I see a bunch of problems with TDD. First of all not all people think and create in the same way. Differences in personality, imagination, IQ, mood all lead to different ways of writing software. Some people naturally feel TDD is the best thing for them, some cannot stand it because it collides with their way of creating value.
Also in my opinion TDD makes people focus on the wrong thing. I think quality comes from well understood problems and good structure. Test should only verify this. They should not replace design and architecture. My prediction is that TDD leads to architectural disintegration because of the wrong focus at every step in the development.
And on top of everything, some complex code might not even be testable (think multi-threading) without major headaches.
I prefer Thought Driven Development.
3. Design patterns
The problem with design patterns can be summarized this way: “when you have a hammer all problems start to look like nails”. Many programmers consider them solutions even before understanding the problems they face. I was once accused by a fellow programmer that I messed up with the singleton principle when I wrote a class that managed more than one instance of itself. When I responded that I didn’t care about the mentioned principle he wanted to beat me with the GoF book.
4. UML as programming language
A couple of months back I wrote a full post about how I feel about UML – 13 reasons for UMLâ€™s descent into darkness. The value of UML, in my mind, was always to facilitate discussions between designers. But please, pretty please, don’t force me to generate empty code shells from UML diagrams created with insanely expensive tools just to get hundreds of pages of useless pseudo-documentation.
5. Open concept
I know of companies who force the so called “open concept” at work. This means everybody works out in the open. No private offices, no cubes, sometimes not even fixed locations. Managers who do this to their programmer have never been programmers themselves. Distractions kill a programmer’s productivity. Programmers are often described as very intelligent people with ADD. They can concentrate as long as there is no distraction. Repeated distractions make them zero productive. Everything is well explained in Tom DeMarco’s book Peopleware.
6. Exception handling in Java
In Java world there is a debate between two camps. Some favor checked exceptions while others consider them a failed experiment and propose a migration to unchecked exceptions. Again the focus here is on the wrong thing. The important thing to remember is that your code has to deal with failure scenarios. Checked exceptions are just a way to remind you about this annoying fact. Checked or unchecked you still have to handle exceptions or your applications will fall flat on its face sooner or later.
For my full opinion on Java exceptions start reading here: Exceptional Java – Thoughts on Java exceptions
7. Code reviews
Code reviews as in Fagan style code reviews are wishful thinking for lots of organizations. My opinion is they focus on the wrong goal – finding defects. As a dogma this practice forces you to fake code reviews because there is no way in hell you can inspect all the code by the book. Once I even got this lecture from a code review Nazi: “Code reviews should happen before testing the code at all, just after a successful compilation. This way we can find more defect during the reviews and the effectiveness of the review is greater!”. Sadly, I am not joking.
8. Code comments
Here we have multiple dogmas. Some people want no stinking comments in the code. Just write clear code and use good naming conventions. Others are very pedantic and want ample narrative comments all over the place (see useless comments for getters and setters in Java: “getX() gets the x, setX(x) sets the x”). Both are reasons for terrorizing programmers from a position of power. Both are wrong – one should comment no more and no less than what is needed to make the code maintainable.
There are lots of other examples but I think I made my point: There is no silver bullet in software development!
There might be TAO in every method you encounter in the software industry, but not when applied blindly.