Challenge everything

Challenge everything, accept nothing at face value.

Drive this philosophy into everyone in your software organization from marketing and sales to project management and individual team members and good things will follow.

But why? Isn't challenging people's decisions and choices destructive? Isn't it mistrusting your colleagues, and slowing down work? Instead of getting things done, you spend time discussing the same issues over and over again when everybody has their round of challenging? Doesn't it set up kind of an environment where people constantly have to defend their ideas, and provoke confrontation?

That exactly is the point! Sparring ideas, working them on the whiteboard and discussing them over coffee is cheap. Spending months implementing the wrong features or bad marketing strategy is expensive.

Challenging everything is really a safety net for your organization. It prevents brainfarts from destroying your business or technology. It is also a personal safety net since it allows you to test your ideas in a safe environment. It is better to have a trusted colleague torpedo your cool idea right from the start than fail publicly six months later, is it not? And imagine the kind of confidence you can proceed with your Next Big Thing after you have had your first five sparring sessions about it.

Building an environment and culture that allows ideas to be challenged may be difficult though. It requires certain maturity from the involved, they have to understand that it's people's ideas that argue, not the people. It helps to keep in mind that the word challenge is not a negative word, it is just a request for more information or a sanity check. Challenging is not a destructive or distrustful process but a process for creating mutual understanding and confidence. It is the starting point for a conversation, not a finishing one.

Avoiding rumpling other people's feathers is tricky, but the actual act of challenging could not be easier. Just keep on asking "why" until things make sense to you.


A real-life example

Here is a (pretty convoluted) example. In a certain project in the past I was re-designing a public interface of an accounting system that, among other things, processed monetary transactions. A function of that interface was to transfer money to a user's account. The function had four parameters: transaction ID, account ID, and two monetary amounts.

Two moneys? Why?

"Because for taxation reasons - or something like that - certain transactions cannot be deposited in a lump sum" said the architect of the accounting system. OK, fair enough, but sounds like he is not completely sure. I checked with the architect of the business system using the accounting system, who told me that the accounting team demanded the feature for taxation reasons, and that the reporting team also has a stake. So I call up the reporting people, who tell me that the feature is a pain in the ass but that it is very important for the customer and the accounting team requires it. They also mentioned that a fourth team who monitor the transactional integrity of all system has a stake. So I contact the monitor team, who are a bit confused about my question and in the end could not care less. At the same time a business person - after double-checking with the customer - confirms that the feature, in fact, is not needed.

Very interesting, I thought. Everyone takes the feature of splitting lump sums for granted. After all it is an feature supported by three different systems so it must be needed by someone! But no one knows by whom.

In the end I spent two months bothering fifteen people from four teams to remove a single parameter from a function. Of course functionality considered "a pain in the ass" could now be removed from three systems which would simplify the life of four teams.

Buy why was the rather expensive feature that no one needs implemented in the first place? Certainly there is fault in the software process, but would this had happened if any of the people involved had challenged the need for the feature?

Morale of the story: it may take more effort to challenge the rationale of doing something than just doing it. But it probably pays off in the long term.

Which brings us to...


Impact on software architecture

Simple software is cheaper, runs faster, is easier to use, document, test, deploy, operate, maintain and is generally more pleasant than complex software. Common sense dictates that software should be as simple as possible (but not simpler). But how to make simple software?

Using the latest programming paradigm? Buying the fanciest Enterprise Platform on the market? Grabbing the hottest open source framework where you don't have to write code anymore, just configure XML, use annotations, or let the built in artificial intelligence run the show?

Maybe not. As a function of features complexity increases exponentially, not linearly. Therefore the key to keeping things simple (stupid), is to minimize the number of features and moving parts in your software. Disciplined processes for capturing user needs and designing software can help, but the key thing is simply to challenge the necessity of every feature and nut and bolt before adding it to your system.


In short, challenging everything

• Is a cheap way of improving ideas, and weeding out bad ones


• Builds mutual understanding and trust, and kills assumptions (the mothers of all fuck-ups)


• Is a safety net that prevents your organization from doing stupid things


• Is a personal safety net that prevents you from doing stupid things


• Can be challenging :)


• Is the basis for good software architecture

The lesser primate committee thinking experiment

Start with a cage containing five apes.

In the cage, hang a banana on a string and put stairs under it. Before long, an ape will go to the stairs and start to climb towards the Banana, but as soon as he touches the stairs, spray all of the apes with cold water. After a while, another ape makes an attempt with the same result-all the apes are sprayed with cold water. Turn off the cold water. If, later, another ape tries to climb the stairs, the other apes will try to prevent it even though no water sprays them.

Now, remove one ape from the cage and replace it with a new one. The New ape sees the banana and wants to climb the stairs. To his horror, all of the other apes attack him. After another attempt and attack, he knows that if he tries to climb the stairs, he will be assaulted.

Next, remove another of the original five apes and replace it with a new one. The newcomer goes to the stairs and is attacked. The previous Newcomer takes part in the punishment with enthusiasm.

Again, replace a third original ape with a new one. The new one makes it to the stairs and is attacked as well. Two of the four apes that beat him have no idea why they were not permitted to climb the stairs, or why they are participating in the beating of the newest ape. After replacing the fourth and fifth original apes, all the apes which have been sprayed with cold water have been replaced. Nevertheless, no ape ever again approaches the stairs.

Why not?

"Because that's the way it's always been around here."

Sound familiar?