Dreaming of an Ideal World!!!

Continuing on my building construction and software series…

Today, I took the following picture.

Looks like this is a car parking area. As you notice some amount of work is done including the plastering and now, they can start construction on top of this.

For me, this is more like providing a library so that, my consumer can start using the interfaces from my library. But, there are differences.  Look at this picture…

1. Only what is required for the next phase is completed.
2. Finishing will be done once the basic structure is completed.

Can we do this when I deliver a library or module?  How much of the work should be done before some one just start using the library and build his/her component?  When do we do the finishing?

Re-usability

That’s when I started thinking about re-usability.  People always compare about building construction and software development.  The comparison is always about predictability of the schedule and design in a building construction.   But, do we ever think of re-using anything from a building when you move on to construct another one?  I think this is true for civil engineering and manufacturing.   All that we use are resources such as men(workers) and machineries.  But, in a software development, the emphasis is on integrating a bunch of components or modules and then spending 80% of the time on fixing integration issues.

More on this later….

Last time, I talked about our new facility.  I mentioned that this building was completed in a record time of 12 months.  There is a nice break out area on each floors.  Girish and myself have our lunch here daily.

Given below is couple of views from this break out area.  As you notice, another similar type of building is coming up next to our building.

Just imagine that you are designing and building a software.  Can you imagine that you are building the initial libraries or modules or what ever you call it here.  Does that look like these images.  How do we compare our low level libraries with these buildings.  For me, the foundation and the pillars that they raise  are the real backbone of a building.  Everything is constructed around these foundation and pillars.  You can not change the foundation or pillars once they are constructed unless you start from 0 level. 

If I take the above analogy to my software,  the components I choose are the foundation and the interfaces I define are my building blocks.  My interfaces are built on top of components.   Change in any of them is like starting the project from day 1.

I forgot to mention this. Early this month, we moved to our new facility. This is quite a distance for me. Though, the surrounding is better compared to where we were earlier, the facility itself was disappointing. Here is our new office building.

and a new meeting room, where we can have our standup meetings.

Many of our executives came down for the inauguration of this building, including our CEO, Ron Hovsepian.

Plans to move to a new facility was announced in last February and it was mentioned that we will move to a new facility by next April. I must admit that the people managed this project kept their words and we were in our new facility in this April. What caught my attention is a mention about comparing Software projects with bringing up a facility like this during an opening address by our MD, Naresh Shah. He stated that our project managers should learn a lesson from this.

And, that made me think. What are our common excuses for schedule slippage?

• Changing requirements
• Technical challenges or change in technology
• Slack in dependency management
• People
• Pressure in giving a schedule before you study the project

Now look at this scenario. Don’t you go back to your architect with a new idea when you construct a house or other buildings? How much does he accommodate? Don’t you think there are challenges when you construct a house such as new materials, delay in getting cement, steel etc. More over, handling construction work at Bangalore is another challenge where you can’t get anything done on time unless you sit with the workers.

On the other hand, I think I can always deliver the project on time, if

• I decide what the customer needs
• No beta deliveries and no feedback from customers
• Customers don’t have a choice but to use my software
• I deliver the project on the scheduled date in what ever condition it is and the customer is forced to use the product with or without my help
• I will continue to build and deliver my product with no communication, though the customer has deployed the product in his production environment.

Do you think all projects will be successful in such a scenario?