Gazing out of my balcony, looking at some passing chicks ;-) my attention went towards the building construction happening at the adjacent plot of my apartment. Unintentionally, I started observing the set of activities that was taking place at the construction site and I started following the what the workers were involved in. While giving a little thought on each of their activities, I could actually relate them to the all the activities involved in a Software development life cycle. And I thought, there is absolutely no difference between a civil building construction and a software construction. Then why do we see, loose software, delays, bugs, errors, bad design, and all sorts of ill effects of a bad software and don't find any such thing in a building construction. We end up getting a building which becomes an apartment for many, has a life of at least 100 years as per the Civil Engineering principles.
Here's what I saw... (In no specific sequence)
- A Person measuring the Iron rod required to be used for the RCC (Concrete column) and cutting it in appropriate size. Each floor had more than 50 pillars, each pillar needed 6 rods. So all he was to do was measure the length from the bulk rod, and cut it to a "instructed" size. In short, he had to do 300 of them. Let me also tell you, this set of output was for the next floor and not for the current floor that was getting constructed.
- Another person bending another set of already cut rods to "instructed" rectangle size to actually hold the rods for a pillar. That's all he needed to do.
- A team of 10 involved in making the concrete mixture. 6 of them were to just move get the measured quantity of sand, rock pebbles, cement and water. 2 of them for each item and they knew what they had to do.
- A supervisor with a small chart in hand to check if the quantity of the items he estimated for a floor was actually enough for actually building that floor.
- A separate team of 4-5 involved in plastering the floors that are completed, not knowing what the others are doing.
All these and lots more were happening absolutely flawless and without anyone talking even a word. Of course, there were jokes being cracked by each one of them to keep themselves active and happy while they were working, making their day at work enjoying!
I might sound too silly, but the whole scene was just awesome looking at the fantastic team co-ordination.
That's exactly I would (for that matter everyone would) expect in case of a software development project.
- First and foremost: Requirement is clear and is almost frozen (Although External changes and room for expansion and high level modification permitted and provided room for) - In a civil construction, this is the Artistic view and the architect's blueprint.
- Have sub module blueprints of the architecture with reference to the main one. - In civil, this is the floor diagram.
- Have the Technical Architecture, Object Model, Data Model and the Design specifications as accurate as possible. Have frequent check lists at various points.
- Have a very detailed project plan. This is very important. The entire development phase should be on paper with accuracy to the greatest extent. Even the smallest module should have its low level design on paper. (Please note, this doesn't have to be a proper documentation. It can be a scribble in a piece of paper, as long as it is available handy during development of that module :-) )
- It is said that the ideal Software development life cycle has - 30% design, 40% development, 30% testing and validation. Although I would prefer 40% in design and blueprinting each and everything before the development starts, but at least not 40%, see to it that you utilise the 30% earmarked for design effectively and truthfully. I am sure everyone would agree to it, that spending more time in design (even if there is a slippage for the development to start) is worth it since the development would be faster and more or less monotonous.
- Allocate the modules to people who are specialised to do that specific piece of work. E.g. A person might be very good at usability and UI development. Make sure he or she is entrusted the task they are best at and so on. Everyone should know what they are constructing and how is it going to be used in the next upper layer. Involve the team as much as possible. The integration can be managed by module leaders and team leaders, and hence they need to know precisely what their deliverable are, what is their end product and most important, how is it going to fit in the overall system.
- Design documents should be used by the developers as a task guide, and hence see to it that the design documents for each sub module is as accurate as possible.
- Most importantly, plan the activities in such a way that the modules which need to be integrated with other modules are ready before the integrating module is just about to complete or completed. The next set of modules which can be independently developed can start in parallel by a different team. In short as I said earlier, the Project plan should be as accurate as possible.
There are many such points which can be blindly picked up from the way a civil engineering works and incorporated for software development. I have just tried to highlight the importance of having the design and blueprint accurate and complete before the development starts.
I am sure many may disagree with me to this, with a reasoning that we get very less time for software development and this does not arise is not the case with civil engineering.
The civil engineering is more than 500 year old industry and hence the ultimate aim for the software industry is to reach such accuracy that civil engineering follows.
But, with all my previous experience, I have uniformly noticed one thing that, totalled time taken for bug fixing and maintenance plus the initial development, in case of a quickly designed projects, is much more than projects which are accurately and designed in detail. There may not be any visible output early but the end product is not only sturdy but also long lived.
So that was my day on a boring Saturday which turned out to be a very fruitful one. So next time when you come across a building getting constructed, just try spending an hour or so just to notice the set of activities they do and just try to relate it to the software development life cycle and I am very sure, you would end up getting a better understanding than what I have written :-) If I knew to write great articles, I would have been an author of few books by now :-D I am very poor in expressing stuff and explaining, and hence I sincerely hope the message has been passed through successfully.
