Tactics
Jonathan Wilson is one of the best analysts of the Beautiful Game. He answers an important question: what is the relationship between players and tactics? and then I ask does this have any relevance to software engineering?
His article breaks tactics into two layers: base and superstructure:
Base governs which side creates more chances and what sort of chances they are; superstructure determines whether those chances are taken.
Of course, it is more complex than that. I wonder if there is an extra layer: the skill of each player. Perhaps this is part of the base. Skill is divided into the innate, and the part that can be taught–usually in the long term. It is not the same to have Messi, Falcao or Ronaldo in your team compared to Chris Wondolowski. Rich teams can improve this part of their base with signings, hence the reason we are seeing the establishment of the era of the Super Teams in EUFA.
There is another part of the base that is essentially the work that a coach does for a team. This includes the organization of the team on the field, the design of set pieces, the preparation before each game, the designation of the starting 11, substitutions, etc.
And this helps explain why I admire some coaches, such as Pellegrini, who with a weaker base of players, can create a team that can compete with the best in Europe. I think he will be spectacular in his new job at Manchester City.
Then it comes superstructure, which is the non-deterministic part of the game, and why we are not playing with robots.
In Wilson’s words, the objective of the tactics is to reduce the chances to score of the other team, and to improve your own. His analysis makes me think of Moneyball. One of Billy Beane’s goals was to get players that improved the chance to score runs for a team.
Which brings me to software engineering: Software development is a team sport. Any software development team has players with their own /base/. Some are better than others. We can always go out and try to hire /better ones/ (based on pure skill). We know that some programmers can be as productive as 10 times others. html:
There is a part of their base that can be taught. I always wonder why managers are not more proactive at teaching their players how to improve their debugging or editing. It is as if these skills are expected to be learned on their own. As if we are knowledge workers, not production line ones, even though frequently we would benefit from learning how to improve our processes as if we were in a production line.
Now, imagine you were just promoted to be the coach (the manager) of the team. You might have a chance to make few signings or you might have to be content with the team you have (unless you work for a Super Team —e.g. Google— where you might have a lot of money to hire the best) . Say you get a budget, what type of player would you hire?
Think about it. If tactics play a role in software development, then we need to choose a player that fits the team, and makes the team better; not necessarily the best player available in the market. And who works better for the team might not be the best developer out there. For example, a team might be better of with a great tester than with a productive software developer that hates testing. Are these decisions considered by a typical manager? I don’t know. html:
Now, if we take a Moneyball point of view, we should start to align features of players with their ability to create chances to score. In software development teams this means the chance not to screw up. Software development teams are combination of individuals each with unique strengths; if the manager is able to create a good base around them, they will be able to produce more than working individually (even if working towards the same common goal).
I have had a SE manager that was a good tactician (I had around 10 in my life as a developer). I wonder if they exist. Usually they care about tracking deadlines, and break the work apart so each of us could do our part, but I never had a feeling that we were working together supporting each other as we completed our work.
I am sure there are certainly software developers that make their teams better around them. I think we need to learn to quantify this. And we need to learn how to make software development managers better at improving their base.
–dmg