Leaving it for the developer to decide

Most junior and senior developers have one simple incentive; Investing in their own future. The way they tend to do this, is by acquiring more knowledge about potential things they imagine future employers will be interested in. This way the developer makes himself more valuable to any potential future organisation and employer, until he reaches the point that he has made himself indispensable. This creates a problem, which is that the developer’s incentives is in direct competition with his employers incentives. In fact, the incentives are arguably aligned in completely opposite directions.

At the same time, the employer is 100% dependent upon the developer’s opinion and advice, because he is the only one adequately equipped with the knowledge required to make choices of technical nature. This results in a “wag the dog” situation, where the most capable individual to be making a decision, is also the least likely individual to be making the correct decision.

For instance, if you ask an average developer how he feels about some component that solves some specific task, he might find the challenge of creating a similar component more intellectually challenging than simply reusing something existing. This might result in that the developer will be looking for flaws in the component his employer asks him to evaluate, in an effort to discredit the component, trying to convince his employer that he would be much better off letting the developer implement a similar component for himself. This would be in alignment with the developer’s incentives, which is to make himself more valuable.

The expression “wag the dog” implies that the tail wags the dog, instead of having the dog wag its tail. Similar expressions have been made that are of more explicit character, such as “the inmates are running the asylum”. Regardless of how you look at it, if you let the developer alone to mind his own business, he’ll probably do what’s in his own best interest, which is to accumulate more technical debt on behalf of his employer, happily coding away, one line of code at the time – Until the cognitive overload of the organisation as a whole, is so large the organisation can no longer sustain itself.

But why should the developer care? He already have 20 new job offers at LinkedIn, which he now is far more likely to be able to fill, due to that he’s learned all those new and shiny things, while breaking the back of his current employer.

Congratulations, you’ve now entered the “wag the dog” world, happily allowing your “inmates to run your asylum” – You’re no longer in charge of your own organisation, because you allowed your “most competent individual” to make your decisions

This will probably come as a surprise to you, but allowing your most intelligent resource to make the most important and hardest technical decisions, will only result in more intelligent objections against using the most intelligent solutions.

Advertisements

Cognitive overload

If I asked you what 7+5 was, you’d probably be able to give me an accurate answer within a couple of seconds. If I first asked you what the square root of the population of Uganda was, multiplied by the circumference of the Earth, and then waited until you were thoroughly engaged in solving this problem, for then to ask you what 7+5 is – You’d probably not even be able to give me an answer before a minute or two had passed. That’s because your mind would be preoccupied with problems to such an extent it doesn’t have room for more problems. This is called “cognitive overload”.

Cognitive overload happens in everything that computes, including computers and human minds. For instance, if you install a million apps on your computer, for then to start all of these apps at the same time, and then try to read the news with your browser – Chances are your computer won’t even be able to start your browser. However, also organisations can experience cognitive overload, and when they do, they become completely paralyzed, and no longer able to function – The same way your computer does when it has too many programs running simultaneously.

This is just one of the side effects of technical debt, as in too many tasks to do. Whatever you can purchase or obtain somehow as off the shelf components will reduce your organisation’s cognitive load, and hence makes it free to solve its more important tasks – As in the tasks that are of strategic importance to you and your organisation. All other tasks should simply not be solved, at least not by you or your organisation.

And, if you have to solve a problem, because it is at the core of your strategy, then please break it down into multiple smaller problems, since this allows for you to solve the smaller problems, without having to fill your mind with non-important stuff you know you can solve after you have solved the initial problem. Walking up a staircase is simple if you only move one step at the time. If you’re standing at the bottom of the staircase, trying to jump to the top in one step, it becomes literally impossible. In fact, this is an ancient Roman war strategy, but works just as well for solving problems in a software development department as it does when it comes to conquering Gaulle.

In one of my future articles, I will illustrate a use case describing how you can break down an actual problem into multiple smaller tasks, allowing you to more easily avoid cognitive overload, and such create a more healthy organisation and software development department. However, the idea can be summed up with a simple sentence.

The road to reach your dreams starts with one small step at the time

In fact, this is the most famous quote probably ever uttered, and it is as follows.

One small step for man, one gigantic leap for humanity

And that’s because it was just the final step on a staircase filled with trillions upon trillions of solutions to tiny small and easily understood problems. But trying to jump to the moon before having solved these problems, one at the time, becomes the very definition of insanity. Hence, do like Neil Armstrong please, and do it one step at the time …