Category — Books

JP Morgan’s research report on investment ideas in the internet space has just come out. The document is quite comprehensive, actually too comprehensive and technical. However if you are game for some serious reading then you can download the pdf here

You must have heard about Issac Asimov. He was one of the best known science fiction writers in the world.

He is the person who gave us the Three Laws of Robotics.

Asimov thought that The Last Question, first copyrighted in 1956, was his best short story ever.

Do take out a few minutes and read this. If you have even a little bit inclination towards science, you will love this.

Links:
- http://filer.case.edu/dts8/thelastq.htm
OR
- http://www.multivax.com/last_question.html

PS: Do not read the end first, if you really want to enjoy this.

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.