Sean’s “Holy Crap!!” Rule

This is an interesting idea that Sean mentioned in one of our offsite cross functional meetings. Someone was presenting an estimate and a plan to achieve a certain milestone. All of us in the room were debating on how that was too much of work to be completed in too short a time. Sean, who was sitting across in the room, then mentioned these words which immediately struck a chord with everyone. He said, “This is a Holy Crap estimate. Many times after doing an estimate when you sit back and look at the number you feel Holy crap this cannot be true!”. All of us were laughing and then I thought this is so true. We are often faced with a situation where we know that the scope and timeline are at loggerheads. Yet we go through the motions and try to squeeze the numbers and dates by making some ridiculous assumptions. All of that just to arrive at what we think is a palatable plan. If you look at it from the outside, your reaction is going to be same. Holy crap, that is impossible. I think many managers figure this out but do not have the courage to call a spade a spade. Then what follows is a predictable disaster, if the project gets approved.

Some other variations of this rule that I have heard are

• “What is he smoking?”
• “Is he nuts?”
• “You can’t use nine ladies to produce a baby in one month.” and finally one very peculiar one that I heard recently
• “You guys are stitching together lot of parts and calling it an elephant. That ain’t going to fly.”

No matter what you call it, I think rule deserves a prominent place in every leader’s memory so that he can put the hypothesis to some reality check. It will save a lot of projects from getting started with very ambitious (read unachievable) plans.

Read more...

Software Projects are still a Tar Pit

I don’t mean to claim any rights to use this analogy because this is how Dr. Fredrick Brooks described Software projects in his very famous book titled “The Mythical Man-Month: Essays on Software Engineering”. This book is undeniably the most widely read book on the subject of software project management and, although some of the examples are dated, many of the lessons remain highly relevant today – and unfortunately still often unheeded. Every time I have read this book I have found it interesting and I have also related a few of my recent mistakes to the examples mentioned in this book.

Dr. Brooks wrote this book based on his experience as a project manager for IBM’s OS/360 project. After he left IBM he became a professor at a university in the states and that is when he authored this book. The tendency for managers to repeat such errors in project development led Brooks to comment that his book is called "The Bible of Software Engineering" because "everybody reads it but nobody does anything about it!"

I recommend this book as a MUST READ for all of you who manage and work on software projects and I am sure you will find those “a-ha” moments as you read the book. Here are some of the lessons, and my interpretation of those.

1. Question: How does a large software project get to be one year late? Answer: One day at a time!
   One cannot highlight the importance of tracking progress more crisply than these words. Managers often track the effort rather than the milestones. The definition of the milestone is not very crisp and that leads to what I call a Green-Green-Red phenomenon. So as you track the so called progress (actually the effort burn rate) all the tasks on a plan seem to be in good health with a Green indicator. This status continues to be green till about 70% of the total effort is burnt and then suddenly the realization dawns that there is lot more work left to be done. The status suddenly changes to Red. So the question I often ask in the status review meeting is how much time (effort and schedule) is required to complete the remaining work. That is a very good measure of completion and progress than the effort spent. Secondly, I think a lot of managers are averse to reporting the lack of progress on the project. The eternal hope is that “we can catch up next week”.
2. People and man months are not interchangeable.
   There always is an optimal team size to complete any project. Any team smaller or larger than this is counterproductive as far as the cost and schedule is concerned. The derivation of the schedule from the total effort is not a mathematical formula because the level of complexity of communication cannot be factored into the formula. As the saying goes, you cannot produce a baby in one month with nine women. The schedule is a complex function of the task on hand (which defines the effort and the skill set required), the number of people available and the number of parallel tasks that can be run.
3. Adding manpower to a late software project makes it later.
   This is yet another classic and one encounters this quite regularly in the software industry. During the initial stages of the project, resources are either not available or they do not have the right skills and towards the end as the pressure mounts to meet the deadline people try to add resources. Addition of these people is really not going to have any positive impact on the schedule because they have a learning curve to cope with, they need to be brought up to speed on the project and processes and then start delivering work. So instead of helping the team they often end up being a drag on the team that is running full steam ahead.
4. Second System Effect
   Almost all of us who have designed systems must have made this mistake. After burning our fingers with the mistakes in our first project, the reaction is to over engineer the second system to an extent where the design almost becomes impossible to develop/maintain. Every conceivable design idea is embraced in the hope that there would be no errors.

It is not as if we have completely turned a blind eye to the recommendations in this book. There are quite a few other topics that are covered in this book and have been rectified to an extent in the present day. Finally I cannot resist the temptation of quoting this verbatim from the book. This paragraph sums up almost all the themes mentioned above.

“That for a programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelette, promised in two minutes, may appear to be progressing nicely, but at two minutes may not be set. The customer has two choices – wait or eat it raw. Software customers have had the same choices. The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save – burned in part, raw in another. “

Well think of all the omelettes that you have served so far :).

Read more...

Why is it not Engineering?

So why is Software Engineering still an art rather than science? Let me try to address this issue based on my experience and the knowledge, I don’t claim to be an authority. In my opinion, this is due to multiple factors.

1. In the early days of computers and software, the landscape was full of proprietary OS and DBMS systems. So a single common measure of productivity across platforms was not very easily available. So if a system was developed on CICS/VSAM platform or VMS/Rdb the productivity and effort numbers were quite different although the functionality remained the same. Very often the decision was based on the cost of the hardware and the reliability that it offered. Therefore IBM was miles ahead of the competition. Although their software stack was very complex to use and maintain, they had a rock solid hardware that could handle loads and could guarantee reliable up time.
2. The improvements in the hardware and software technologies have been at a very rapid pace. So the target solution and the benchmarks had to be continuously assessed on newer unknown platforms. There was always a ramp time to learn and assimilate the newer tools. The vendors claimed productivity gains during this time but largely these were not proven in the market. Hence the practice of estimating an effort on one technology and then extrapolating that with assumptions to newer technologies came into existence and with it also came in the ‘factor of safety’ added by the developers to protect their estimates.
3. Tools which increased the productivity such as the CASE tools started getting into mainstream development projects and that too impacted the productivity numbers. The evolution was from the flowcharts to DFDs and HIPOs through the ER diagrams. As the relational model of the database became the standard, the tools also started converging and the design artifacts started getting standarized. Again the landscape was changing rapidly on this front too.
4. The estimate, even today, is very often a fitment exercise to arrive at a number that either meets the budget number or a deadline or some similar objective. It is often padded up and down several times to account for the unknowns but as the negotiations start these buffers soon start flying out of the window.
5. Customer requirements are not very clear and precise, or there are no tools to capture them in a very clearly agreed and understood manner. The answer to whether a piece of code meets a requirement is never a Boolean yes or no. This coupled with the large lifecycles of the projects leads to a situation where the stakeholders change and the requirements keep changing. Project Management practices have evolved over time to manage this scope creep to an extent by agreeing to a set of deliverables and stalling the new requirements till then.
6. Finally, I think the technology community is obsessed with working on the “bleeding edge” tools and technologies and therefore they influence the decisions to go for the latest when it comes to deciding which platform to use. There often is not enough information available to estimate the productivity numbers nor do they have sufficient data from the field to check their estimates.

If one were to draw a parallel with the engineering world, say Civil engineering. There is plenty of data available from past projects in terms of material strength, labor productivity, curing times, material requirements and the works. This data is standardized and is available in the form of industry design handbooks. So for an engineer to estimate the time and cost required to construct a new bridge, it is almost a mathematical process that leads to an estimate of material, labor and cost. The type and size of material and its strength and price is available readily. I am trivializing this to a large degree but the point is that similar reliable standardized data (metrics) is not available in Software industry. This lack of metrics is possibly the single largest factor that makes the process of Software Engineering very person/organization dependent and therefore an art form.

Read more...

What's in a name

You must be wondering what this blog is all about with a name like that. Believe me I learnt this phrase about 2 years back and it stands for “Scientific Wild Ass Guess”. I quite like the term because it gives an air of authenticity to an estimate and at the same time acknowledges that this is a guess after all. There is nothing scientific about it. But if you tell a person that the SWAG number is 200 person days of effort as opposed to saying that I pulled this number out of a hat, the former is more likely to be accepted. Because it feels scientific, it sounds cool and probably because the audience does not know the meaning of swag.

At the very lowest level swag is nothing more than an estimate where a number of assumptions are made about the scope and the size (effort and schedule) is estimated. We earlier used to have the WBS method or the ‘x people for y months’ method of estimate and both of those will qualify as swags.

So that brings us to the million dollar question as to why Software Engineering is still considered as an abstract art rather than a scientific engineering discipline. I don’t have the answers yet but I will share my thoughts on this topic in the next blog. Till then keep swagging!!

Read more...