BinaryDay

The Mythical Man-Month: Essays on Software Engineering is a book written by Fredrick P. Brooks, Jr. on Software Program Management. The work was first published in 1975, and republished as an anniversary edition in 1995. The main theme is that “Adding manpower to a late software project makes it later.”

You might be thinking that why I am recommending a book written some thirty years back. Even I thought the same when someone recommended this book to me. But after reading this I can without doubt say that this is one of the finest books you will read on this subject. We in industry are constantly facing issues related to project delays, cost over-runs, over complexity, unmotivated employees etc. This book tackles these issues at a very fundamental level. What Fred Brooks experienced as a “father of the IBM System/360″ is still relevant today, even in this age of internet, java and extreme programming.

I have seen time and again that managers think that building a software is like building a wall. You need to deliver a software in six months instead of a year, fine lets put 20 programmers instead of 10. This book explains that this can never be achieved and why it can’t be.

I would strongly recommend this book to someone who has worked in industry (knowledge industry) for couple of years. This would definitely change your view and would make you think (in the right direction) before you take critical decisions.

Some of Brooks insights and generalizations are:

The Mythical Man-Month:
Assigning more programmers to a project running behind schedule, may make it even more late.

The Second-System Effect:
The second system an engineer designs is the most bloated system she will EVER design.

Conceptual Integrity:
To retain conceptual integrity and thereby user-friendliness, a system must have a single architect (or a small system architecture team), completely separate from the implementation team.

The Manual:
The chief architect should produce detailed written specifications for the system in the form of the manual, which leaves no ambiguities about any part of the system and completely specifies the external spcifications of the system i.e. what the user sees.

Pilot Plant:
When designing a new kind of system, a team should factor in the fact that they will have to throw away the first system that is built since this first system will teach them how to build the system. The system will then be completely redesigned using the newly acquired insights during building of the first system. This second system will be smarter and should be the one delivered to the customer.

Formal Documents:
Every project manager must create a roadmap in the form of formal documents which specifies milestones precisely and things like who is going to do what and when and at what cost.

Communication:
In order to avoid disaster, all the teams working on a project, such as the architecture and implementation teams, should stay in contact with each other in as many ways as possible and not guess or assume anything about the other. Ask whenever there’s a doubt. NEVER assume anything.

Code Freeze and System Versioning:
No customer ever fully knows what she wants from the system she wants you to build. As the system begins to come to life, and the customer interacts with it, he understands more and more what he really wants from the system and consequently asks for changes. These changes should of course be accommodated but only upto a certain date, after which the code is frozen. All requests for more changes will have to wait until the NEXT version of the system. If you keep making changes to the system endlessly, it may NEVER get finished.

Specialized Tools:
Every team should have a designated tool maker who makes tools for the entire team, instead of all individuals developing and using their private tools that no one else understands.

No silver bullet:
There is no single strategy, technique or trick that will exponentially raise the productivity of programmers.

There’s been lot of hue and cry about open source in past few years in the technical world. Whatever technical forums or blogs or news you see has some story on open source every day. Some people think open source is the best thing and they want o go open source (though many of them don’t even know the true meaning of open source!) and there are some who think it’s something bad (may be just because they don’t know what it is!).

I would like to explain what I came to know about open source in past three years and what I think about it. (Please beware that all ideas expressed in this article are my personal views, don’t be simply guided by them and believe in what you think … Everyone’s free to believe in and do what one thinks, that’s one of the features of open source).

Do you know the recipe of Coke? I am sure you don’t. Nobody knows (except for the people who make it) because the Coca-Cola company does not tell anyone how they make it . But I am sure you know how to make a good lemonade (lime juice or shikanji or neembu paani) … If you don’t know please first go and ask your mom how to make it, make one and then swallow this article with it .

So, we can’t make Coke at our home but we can make lemonade (probably a better one than sold by a few multi-national companies).
Now let us look at some other facts related to Coke and lemonade…
We pay approximately 20 Indian bucks for 500 ml of coke bottle (you may pay upto 30 Indian bucks for the same thing if you buy it at a multiplex). Making 500 ml of lemonade won’t cost more than 7 or 8 Indian bucks (just the cost of two lemons and some sugar, water is free).
We always get coke as it is, wherever we buy it. Yes we can add stuff to it to change its taste but the basic thing remains same…though most of us won’t mess with a 20 bucks cost (probably not worth) thing. But in case of lemonade we are free to modify its recipe as we like… choose the number of lemons, quantity of sugar, type of lemons, etc. We have to trust the Coke company when they say that they use clean water and ingredients that don’t harm our health. There’s no other way to know the truth unless you know a food inspector who won’t take bribe. But in case of lemonade we always know how good or bad the ingredients are that are used.

I guess by now you think that I want to say that lemonade is open source and coke is closed source. Yes you are right if you think so. Lemonade is open source because the recipe(the source ) of lemonade is known to all and coke is closed source because we don’t know how it is made.

Since this article is on BinaryDay, a few technical words…

Comparing the above to software industry, an open source software is one for which the users know the source code written in C, Java or any of the hundreds of computer languages (the recipe) of the software and closed source software in which you get the compiled executable file but you don’t know the source code (the recipe) of the software…You know what it does but you don’t know how it does.

There’s a very common question that people ask . “How to make money with open source?”
Most people’s answer to this question is a very moral one… “Not every work should be done for money”… True, but how practical is it? Not at all. What’s the point in burning your brains out when you can’t buy even a laptop or a bike? The philosophy of open source does not stop one from making money. People generally take free software to be free in the sense of “Buy two, get one free”. That’s not the correct meaning . The “free” in free software is free in the sense of “freedom”.

Let me again bring in some coke and lemonade to explain the money part and the freedom part of open source.
First the money part. We all know how to make lemonade but still we buy it in a shop or order it in a restaurant.(I guess lime juice is the most sold thing (in terms of quantity) in our college canteen!). We all buy a thing which we know how to make (sometimes even better than what we buy) because due to some reason or the other we can’t always make it ourselves.

Consider one more thing. If you make your lemonade yourself there’s no guarantee that every time you make it, it’s equally good. But a good restaurant can guarantee that and that’s one of the things they charge for.
Similar is the case with Software. Companies buy software just as we buy lemonade. But why will a company buy open source software rather than a closed source software? (Or why will I buy lemonade rather than Coke?) The answer is below in the freedom part.

If we order lemonade in a good restaurant we can always ask the waiter to tell the person who prepares lemonade to add less/more sugar or to add a pinch of salt or to add extra lime juice, etc. The point is that we can get it customized according to our taste. Whereas in case of coke we don’t have such “freedom”. That’s one of the reasons why I prefer lemonade and former President of the Republic of India, Dr. A.P.J Abdul Kalam prefers Open Source software for the Indian Armed Forces.

There’s one more issue I would like to discuss.
When we make lemonade for the first time, or bake a cake for the first time or for that matter cook anything new, we always ask for help from someone, mostly our mother (all mothers are expert cooks, that’s why we have so much good food in the world), who knows to make it or knows to make something similar (in case you are creative with food and try new recipes). When we have made our new recipe we want everyone we know to try it out (We don’t charge them). If our new recipe is good enough and people like it, it’s very likely that they want you to make it again and again and if it’s really great you may end up making money by teaching the chefs of a five start hotel how to make it.
Same is the case with software, you always get help from people in the online forums. You make a new software and give it to people to try it and if your software is real good, it may be the next MySQL (MySQL is the world’s most famous database software, it is open source and was bought by Sun Microsystems a few days ago).
That’s how somebody once made a burger and Linus Torvaldz made Linux !!!

Food and Software are so similar, aren’t they?