I received this mail from my father yesterday and it rang a bell in my head concerning how software teams are managed. I though I would share it with you, with my thoughts added.
The Inefficient Concert!
The CEO of a company fell ill on a day when he had tickets to see a concert. As a gesture of kindness, he gave the tickets to the company’s efficiency expert, to enjoy with his wife. Next morning, the CEO was surprised to find a report on his table, written by the efficiency expert, and this is what it said:
Dear Sir,
I was sent, by you, to the concert, the main piece of the evening being Schubert’s unfinished symphony, although personally I think unfinished work should be disqualified. I have watched the performance and here are some, but not all, of the malfunctions I found:
- The most obvious problem was that they had 22 violinists play the exact same tune! Such reckless waste! I believe that at least 21 of them should be fired.
- The drummer was doing nothing for long stretches of time. I would suggest he be put on a different clock, so we can keep an eye on him and only pay him when he actually does any work.
- Many of the musical segments kept repeating themselves, and I fail to understand the point of having the flutes play the same segment as the oboes. If we can cut down on these repetitions, we can finish the symphony in 20 minutes instead of 2 hours.
- Regarding the equipment: I’ve noticed a horrible lack of standardization when it comes to musical instruments, and especially when it comes to string instruments, I’ve seen small ones, big ones, one you hold under your chin and some you hold between your legs. I think that one size for all these instruments will save time, money and confusion, as well as make maintenance easier.
- The conductor, the most senior employee, did not play as much as a single tune the entire concert, and showed a lack of respect to the customers, while standing with his back (his back!) to the audience. There were even a few times he was threatening his staff with a stick, which should never be allowed. I would suspend him with no pay until we can get to the bottom of this. Psychological counseling may be advised.
To summarize: I am quite sure that if Mr. Schubert had avoided these issues, he would have managed to finish his work, instead of leaving us with an unfinished symphony!
Kind Regards,
Barry
Efficiency Expert
These are the bells that rang on my mind:
- Obviously one man, no matter how smart he is or how smart he can code, cannot create a system. No matter what. So you need many of them. Same as you need many violinists to achieve the sound you want to get from them.
- As in an orchestra, a team of programmers is composed of different people doing different stuff: persistence, view, algorithms, business logic, etc. And like an orchestra playing a masterpiece, each one of them performs specific tasks, which sometimes will not require continuous work, but at the critical moment, he must be there. How do you manage to keep each expert occupied when there is not much work for him? do you give him “regular” task? or do you let him have short days, to keep him ready for the moment where you will be needing him? giving him regular tasks can bore him and cause him to leave for a better company. But letting him work less can create problems with his peers. So how do you solve this?
- There are two possible ways to build a software development team (well, actually infinite ways, but these are the two extremes): a surgical team (term coined by F. Brooks in his must-read book “The Mythical Man-Month“) or the extreme collective code ownership where everyone does everything. I personally like the first one, but from a managerial point of view it has a number of problems, like finding the correct man to lead the team, finding each expert, and most of all, making them work together (this last one probably the most difficult part). Sometimes an average team of programmers working together will create a better product that a group of very smart but cat-like programmers that pass the day discussing which code convention and editor they should be using.
- And last, but not least, the conductor (i.e. the team leader) is not playing any instrument (he is not writing code), but at the same time must understand what everyone else is doing, how they should do it and when they should do it. But what a waste! This guy could probably write half of the system all by himself! But just as the conductor cannot play the whole concert all by himself, one programmer cannot create a full system (and because you are surely thinking of Linus Torvalds, he did not create Linux all by himself. He planted the seeds and directed the growth, but the Linux we have today is the result of hundreds if not thousands of hands hard at work).
If programming is hard, managing programmers is even harder. Good luck!
