88Pro Thinking

"Adding manpower to a late software project makes it later" – Brook's Law

Scene Setting – A 4 member team in a room, having an emergency meeting to discuss ways to avoid a schedule slippage on a module delivery only one developer is working on currently.

Project Manager: Good morning guys... Give me status update and based on that lets discuss how we can mitigate the risk.

Developer: As you know, there have been some unexpected delays due to reasons 1,2 and 3, and I think I wont be able to finish the task in 5 remaining days. I would at least require 2 more days.

After 15 minutes of discussion...

PM: Ok, we will add another person to this module to fast track it, is there any sub component of the module which the new guy can help you out with?

Developer: Ya, there is, if someone can do subcomponent x which is scheduled for allocated 2 days, I can meet the deadline.

One smart guy in the room: We all know the famous Brook's law that adding man power to a late software project makes it later, I can't believe even after it's documented clearly and stated regularly why people still don't understand putting more people is not going to work!!! My god, we never learn the lesson.

I have seen lot of those smart guys (including myself) who have made that final remark quoting Frederic Brook when projects are in critical stages. What Brook said was absolutely true, indeed 9 mothers cant give birth to a baby in a month. Adding more people to a project also introduces new complexities, like communication, co-ordination, etc...

We should be clear that Brook's experience was drawn from a very large project, the development of OS/360 which he lead at IBM.

[Quote]
There wasn’t an exact number of developers who created the OS/360, but it’s in the 10,000 range. Which would make sense if it would take one man 5000 years just to develop what IBM accomplished in 10 years with 10,000 people. Asides from it being grossly over time, the budget was over spent by millions of dollars.
Exact figures of the number of lines of code, but the amount of system resources that it was estimated to use was initially 16K, but after the final version it jumped to 64k.
[Qoute][Source]


When a very small team (1 to 3) working on a component, blindly stating Brook's law is not helpful. If a subcomponent can be developed in isolation, specially by a member who is very familiar with the code base adding that developer will definitely shorten the schedule.

I don't want to reproduce Mythical Man Month here again, however my advice is before stating the Brook's law, think for a second whether its applicable for the “very small” software project you are working on. Most of the time (not all the time) it turns out, it might be not. Lets not misuse Brook's experience will ya.

posted by 88Pro / Saturday, January 21, 2006

Participating in pycontest was very interesting. I was no expert in Python but wanted to give it a try. Took couple of my python books, went to Barista and came up with the first prototype. When I tried to submit my first cut, ooops, the site refused to accept anything more than 345 bytes. after few revisions I was able to reduce it up to 295 bytes.

At that time 120 bytes was the lowest count and everyone who had more byte size knew they are not winning the competition and started discussing their solutions on blogs. Lot of techniques were put out to reduce the byte count. One such blog is gumuz online. As you can see the final winner of the contest André (117 bytes), who is also the first commenter in that started with a 171 byte version and then moved on to 119 byte version refining the code using some of the techniques discussed on that blog.

I learned a lot, I knew I could use lambda/map/list comprehension and come up with a short code, but the main problem I was having is how to encode the pattern in less than 140 bytes. I knew, even if I was expert in python, until I crack the encoding problem I am not going to be able reach 120. One way it was done was to encode the pattern in something other than base 0, for example base 64.

One thing I am really happy about is, I used a (silly)technique in my code to reduce the byte count. If the google team has used the same technique they would have also reached 19 byte count. It is to have everything in one line, separated by semicolon which reduces one byte from your total, since when you put in two lines there is a \n and a \r involved which accounts for 2 bytes.

You might not win anything in these contests but by participating you learn a lot.

Other Links

Journey to 117

posted by 88Pro / Thursday, January 05, 2006

I worked for a telecom solution provider sometime back. When I left the place I handed over the code and did a knowledge transfer to the next guy who is taking over from me. It all went well until recently I started hearing stories about the fact that he thinks my code is crap and he feels like working on top of someone else's dirty code.

SOP It is

I have been in the same boat before, I have thought someone else code was crap, and if you goto http://thedailywtf.com you will see enough of them. However here is an example,

When I started working on a server component of a mobile application, I saw a method names SOP(). SOP stands for System.out.println

Class Utility{
    public static void SOP(String msg){
        System.out.println(msg);
    }
}

Whenever something needed to be printed SOP method was used, and that was a truly WTF moment for me. Since only thing achieved by this is instead of doing a System.out.println the developer is able to do Utility.SOP() whenever he wants to print something. As everyone else I also asked the same question, that is with the latest IDEs anyway you don't have to type much to do a print and why would someone want to abstract it.

Lets try and rewrite this method a little.

Class Utility{
    public static void log(String msg){
         System.out.println(msg);
    }
}

Oh wow, its not really a WTF anymore, its a simple log method, if at all the developer needs to change the way logging worked (like printing the output to a file, or sending to a socket server), change only needs to be done in one place, the log() method. Now it doesn't sound like a WTF anymore does it?

Ok ok, I can hear you saying if you need logging there are so many frameworks to do it, like log4j. However most of the time all you need is a simple logging, specially when you are prototyping something, also if you really look at this, at a later stage it is really possible to plug in a logging framework into this Utility class without affecting the rest of the code.

At a first glance something that looks like a WTF might not be a real WTF at all after all.

There might be reasons

Of course when I look back at some of my code I see lot of areas I could have improved. Specially the RMI Server/Client design itself (something we never got around using). Before I wrote my first prototype I have never seen a telecommunication switch. I was told the Billing System is going to reside in one state and the switches will be in the other states of the country, which prompted me to come up with the client/sever solution which will enable me to plant the server close to the switch and client close to the billing system and everything magically worked.

However when I landed in Micronesia, I realized, we really didn't need a client/server based solution, however I kept the design intact so that in future if at all we come across a situation where we have to plant the server and client in a distributed manner the framework will be still flexible.

I have also explained the reason for going for a command design pattern based solution in my blog previously. You know what, I love that design, it just felt so right and it still does.

All this is not to say there can't be any improvement made to the existing framework. I think it needs few “extract methods” to simplify the clients main() method (I think it does too much work) and things could be improved in few other areas too.

The way results are read from the switch is too messy since it was changed on the fly to suit some messy behavior (unpredictable) and never had the time to look back. However all I am saying is if something looks like crap, think again, it might really not be crap if you know a little background as to why it was done like that, which I tried to explain with my previous example.

Don't rule out the possibility

After all this ranting I don't rule out the possibility of this guy who took over from me being extremely brilliant and sees the entire thing completely differently and at his level of intelligence every normal human code looks crappy, because I have so many times read that at different level of intelligence people see things differently. If thats the case, I would really like to learn a thing or two from him about how to write better code. I really do.

One piece of advice

There are so many different ways of getting recognized as a skilled developer, and calling another skilled developers working code, in so many client installations, crap behind his back is not one of them.

If they had said my writing wasn't good enough, fair enough, that's an opinion. But to say it's too complex is to insult the intelligence of the so-called young. [By Tanith Lee]


posted by 88Pro / Wednesday, January 04, 2006