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:
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!
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!
A friend of mine gave me Rework
two weeks ago after a talk we had over my post on how finishing things helps you finish more, and how overwork starts creeping up on you and causes you to make mistakes (my friend was in one of those one-week deadlines, working 18 hours a day minimum and it was showing). The book is about how to do things in the modern internet-services economy. I think there are many lessons that can also be learned by other fields but not all of them are applicable (for example, in the internet you can have beta versions of a product and the customers will agree to this, but I don’t think I would like to have a beta dishwasher in my house, regardless of how much this can improve the final product).
Bottom line – EXCELLENT BOOK!. It has very short chapters, each having one thing to learn. They tell us that long-term planning is just a different name for guessing, and a good excuse for delaying decisions. Products should be shown to the world as soon as they are useful so that the customers can provide feedback. Things should be simple – if you do a simple thing and you do it right, why get complicated? being simple is not BAD. The bottom line of a business is not size nor number of products, but its efficiency (money per effort). You should have “alone time” to work without interruptions – without having meetings every other hour. And more and more stuff that you can take into practice to make your work, your product and your life better.
You can also go to the author’s site for more information on what they do and their “philosophy”. Great work guys!!!
So go ahead, buy this book from amazon.com, and in the way also contribute to these nice book reviews.
Johanna Rothman‘s blog is one of the RSS subscriptions that I constantly read in my coffee breaks (she and some hundred more RSS… I simply love the concept of content subscription for offline reading). I don’t remember how I arrived at her blog but it seemed interesting and was added to my long list. She has an interesting resume, is the head of a software management consultancy company, has published a number of books and speaks in many conference. Conclusion: she is pretty serious.
In November she started a series of posts on estimating how much time it will take to develop a software product – one of the hardest problems in software development. If we knew how to this, all of our other problems would be solved… if you knew how much time it would take to fix that bug, deciding whether to fix it or not would be easier. The same for that other feature that nobody knows how to implement or test. And if we know, REALLY knew how much time the project would take, the customers would be able to decide which features to remove if they wanted it before this time. Sadly, we are still way far from knowing how to estimate the effort required to fix bugs, add features, and of course, finish the project. Johanna takes the “pragmatic” approach (a word that has become very fashionable after The Pragmatic Programmer
came along), telling us to start working first, understand what you are doing, monitor the speed at which you are going (velocity), try to estimate, work, check your velocity, analyze your estimates, and so and so again. But better to read it from her here:
First, if you are a manager of a software team PLEASE go and read this book (available from amazon.com
) and read it. But only after you have read The Mythical Man-Month). And if you are not a manager, also read this book because it will teach you why it is also important to manage your manager.
After 3 years managing first a team of 4-5 (VERY young) programmers and 2 more years as an system architect and acting manager of three programming teams (3-5 programmers each),
trying to balance being a manager and a software developer who loves to program and wants to do it, this book rang many bells in my mind while reading it. It also explains to you politics an organization, how it is important for you to help your boss even if he is stupid (because he is your image to the upper management), how meetings should be handled and who should be in these meetings (and what to do if they are not there), and much more stuff that is just enlightening. And the writing is clear, concise, short chapters that can be read in 10-15 minutes which I think is just the perfect length.
Oh, and the book finished with the perfect “dessert”: a very rich glossary that is both really funny and sometimes sadly true. Some of my favorites: “Architect: An engineer who knows what he/she is doing”, “Background Check: A pre-hire check employers use to determine whether or not you are a serial murderer”, “Database: A handy place to stick data if you like your data organized and structured”, “HR (Human Resources): Happy people who help you do very unhappy things.”, “Software Development Lifecycle The time between when someone has a clever idea and when that idea is beaten to death and is no longer making money”… I could keep going, but why if you have already bought the book?
Just finished reading a nice article by Fank Buschmann, one of the authors of Pattern-Oriented Software Architecture called Unusable Software is Useless, Part 2.
The conclusion of the article gave words to a feeling I had when managing a software team a couple of years ago and my brightest programmer produced a brilliant solution to a problem we had in the system, only that he was the only person in the team who knew how to implement it correctly (worse yet, he was the only one that understood the solution excluding me). The problem was that he was to leave the team in a couple of months and this new “patch” would become a black box in the system. Buschmann states that “a less optimal but sufficient solution that a team can implement correctly is always better than a smart solution whose implementation requires skills not available in the team” (emphasis mine).
Just another instance of the KISS principle in disguise.