There is no master in modern team

 Of course this is sarcasm, don't take it seriously!

Economics of efficiency

Meet the team

How many Software engineers do you need to screw in a light bulb? One? You are wrong! Let's calculate risks and how we can mitigate those.

What if the Engineer instead of screwing in will start unscrewing the light bulb? Someone will need to ensure that. An extra pair of eyes will definitely help to catch the wrong direction of turning at the early stage, thus saving a lot of time in the long run. This is called Peer review.

But we need to test the light bulb - what if it 's not working? Let's get the Engineers perform the set of tests on the light bulb. Since they are busy testing, we will have to hire two more Engineers to keep up with the work.

What if the lamp is unscrewable, e.g. it has different size or shape of connector? We need someone to tell Engineer what kind of light bulb to use - the Architect will help with that.

What if the light bulb got changed in the wrong room? Or the customer wants a different light bulb? Product manager will help with this.

How about the history of successful bulb replacements - that should definitely help with future installations! Let's hire an Agile coach to teach the team to reflect on their mistakes and re-use successful solutions.



So far we have 4 engineers + System Architect + Product Manager + Agile Coach = 7 people. We now have a TEAM !


Quality calculations

After the project is done we can safely assume the quality of the final solution is going to be very high. But still let's calculate the approximate quality and time spent on an average light bulb project.

Suppose the average Engineer's time to screw in the light bulb is 1 hour and the quality rate is about 70% - i.e. about 70% of work is acceptable. Peer review (in theory) will increase this to 100% - 30% x 70 % = 80%. The time spent will increase by 1 hour.

Meeting with Architect to discuss what kind of screwing method to use will take 0.5 hours of time. If Engineers are less competent with this method, this will reduce their accuracy say by 10%.

Lets see what the customer want, consult with Product manager for 0.5 hours.

And don't forget to listen what other team members are doing, and also reflect on previous work in a short standup meeting for 0.25 hours.

The overall quality is now 80% (70% if different method of screwing is used), and the time spent is 3.25 hours.


Imagine the unthinkable


What if in the beginning we hire an Engineer with 80% quality rating? And get him to do a bit of product management, allowing him to decide on screwing methods?

It's still takes 1 hour to screw in the light bulb. Testing might take 0.25 hours, and in 1 time out of 5 will result in re-fixing the light bulb - so add 0.25 hours. Customer interaction will take 1 hour.

So the quality is still 80%, the time spent 2.5 hours and - quelle horreur! - it's all done by one person!

And if we don't pay this person equivalent of at least 3 people from the team above, he will eventually quit. And the project will halt. That's why it is so important to have a team!


New technologies vs Old logic

The levels of abstraction

A master often invents some kind of system to minimize time spent on trivial tasks. Other people may employ this system to their benefit. Some even improve it. And some - a majority - just blindly copy it without understanding the root causes and original problems the system supposed to solve.

Then there are people who wrap the system nicely and start to sell it to others. In order to increase the value these people add some beautiful decorations and supply shiny manuals on how to use the system.

And eventually some other people start to train others on how to sell the system.

At the end the reason the system was created has long been forgotten, the final solution is bloated and complex and no one quite understands why it should be used - apart from the obvious "it saves time".

What is missing?

Not what, but who - the master is left out of the whole thing. Remember, it was he who invented the system to solve _his_ problems. Your problems may or may not be the same.

So who is missing then?

A person with old fashioned logic. What is logic? What, you did not study this? And I am not talking boolean logic - this is only good for binary devices. Humans are not binary, even the simplest ones. But most humans are not complex either. They make fast-fetched conclusions based on inadequate information and this leads them to mistakes.

A person with old sense logic normally tries to understand the deep layers of the problem. Seeing wider picture (i.e. having broad experience well outside the main skill set) helps enormously during decision making. And all this provides more confidence and less room for error.

So what?

A thorough logical thinking allows to determine the snake oil salesmen early. With enough experience sometimes a few seconds is enough to recognize hype and stop wasting time trying to employ it. Remembering there is nothing new under the Sun will help critically assess all the "new" technologies. Some of these are indeed new and useful, but the majority are just a variety of haphazardly sewn pieces of useless dirty laundry.

It is easy for an average person to be restricted by the set of rules - and it definitely helps a lot during the 'infancy' in the profession. But then experience must take over saying that different rules are for different contexts. Even within each context there are times when it is much easier to bend the rule in order to achieve the result. But only master can do it. And only master can then create a system that will take care of trivial tasks.



Modern problem

There are not many masters around. More over the Software engineering philosophy is based on anti-master principles: there is no I in the TEAM, we follow the rules, make sure others understand your code. This is good for a junior developer, but this will not help him to grow into master, unless he will logically comprehend various levels of abstraction and why those were created in the first place.

Old solution

It's hard to break the circle of never ending "improvement techniques" and "efficiency programs". Most people lack common sense and prefer to use ready made solutions. It works for some, but the overhead is usually hard to calculate and it is not necessarily the best solution. And definitely not the simplest one. However it would be unwise to do nothing about it. I am not talking of destroying the whole software development model, but rethinking the approach to implementing some parts of it. And for every one the final solution will be different - the master should decide what to leave in place what to discard.

Parkinson (The Parkinson's Laws) mentioned that work expands so as to fill the time available for its completion. Similar with the team size - it does not really matter how many members in your team, it will take approximately the same time for small team and for big team to finish the same task. To choose the right time and right people for work again requires master.

The solution is simple. There is only one problem - where to find the master?