Continuous Learning

As promised, there are a couple of software myths that I think are not covered in Robert Glass’s book, and this post will talk about one of them - that software development equates to building constructions. This is a very popular metaphor - first you design, and then you build; just like when we are constructing a building.

Even though this metaphor is popular, in reality it actually is very dangerous and misleading, because it degrades the partnerships between the technical folks and the non-technical (i.e. business) folks and threatens to destroy the values that software projects should create in the first place.

Let me tell you why.

Now - Others have previously pointed out that Software is not similar to building construction, as well as pointing out the horror of command & control style of management. However, while these writings struck a chord with me, they are meant for technical folks rather than business and non-technical folks, when they should really understand the reason and the impacts. In the IT world, business folks matter a lot, both for the project successes and for the general well-beings of the project teams, and it is critical that they can understand the differences. So I will attempt to explain this in a different light. Either I will be successful, or someone else will continue to pick up the torch. This will not be a fast process, but I will do what I can to help.

Because this issue is very important.

We can easily see the similarity between software engineering and building constructions, especially if we are attempting to create something complicated. The famous software project management guru, Steve McConnell, draws a clear parallel when he emphasize the need for proper planning to ensure software success (paraphrased below):

Writing software is like building houses. (Steve actually provides a few different metaphors but appears to like this the best) If you are building a doghouse, you do not need a lot of upfront planning and you can do just fine. However, if you are building a skyscraper, you most likely will fail without proper upfront planning and preparation. (Code Complete, Second Edition)

His point is very well taken. Similar to building constructions, software projects require upfront planning to ensure success. But that is because planning is in general good for achieving any moderately difficult objective, not because software development is the same as building constructions. For example, proper financial planning will help us reach our personal financial goals easier (or so I have been told), and proper wedding planning will ensure the bride entering marriage happily (or so I have been told).

Steve points out that building constructions is a metaphor, and he puts it succinctly:

Using metaphor is a fuzzy business. You have to extend them to benefit from the heuristic insights they provide. But if you extend them too far or in the wrong direction, they will mislead you.(Code Complete, Second Edition)

The challenge here is that we have already extended the metaphor of building construction too far, especially in the IT world. This is something Steve probably could not have foreseen.

Now - why is building construction a popular metaphor? While I do not know the historical context, my guesses are:

1. Buildings are something we can see physically, which help us to visualize software, as software is a completely intangible product
2. Construction is something we are familiar with even when we have not built anything in our lives. We live in buildings and we see buildings built all the time, and we know they cost a lot of money (so we will not be as shocked to see the cost of software ;P)
3. Having a building construction metaphor helps us to create a structure around the software development process, which back then it probably was completely a wild-wild-west shootout

At that time building construction metaphor is probably a wise choice, even though software nature is closer to say, shooting movies or writing books (few people ever try to understand either, so they would not be great metaphors). Unfortunately this metaphor might have become too popular and be taken too literally, especially by business folks who do not understand the actual software construction processes.

Construction has a specific characteristic: there is a substantial material cost, and once raw materials have been morphed into components, it becomes difficult if not impossible to recycle the material to be used for another component in another building, not to mention the associated effort and time. For example, if we cut a piece of wood too short, we have just wasted the wood, unless we can actually use it elsewhere. The "measure twice, cut once" philosophy comes from this world.

For a substantially-sized construction project, say a house (not to mention a skyscraper), construction mistakes can be extremely costly. Hence for construction it is incredibly important to do super-detailed detailed upfront planning and design. Most if not all civil engineering practices have been codified and can be encoded into blueprints, which provides a common language for the construction field. Owners can take a blueprint designed by one architect and hire any competent construction company to carry out the actual construction. Even though not all construction companies are equal in terms of capabilities, their part of the work is commodity, and for the owners the true value lies in the design. For the construction companies, the cheaper, the better.

image source

Also, construction work generally does not require a lot of skills. One can choose to hire an army of cheap labors over having higher skilled labors that can utilize machinery. Great pyramid is still an engineering marvel, and they certainly do not have the machinery back then. I personally was in India, witnessing people manually creating modern buildings.

Furthermore, construction work generally can be partitioned. That is how "Extreme Makeover: Home Edition" can build a house in seven days that generally would take three to six months. Try having a baby that way - see if nine women can have a baby in one month.

And what happens when we take the construction metaphor fully is that we start to associate all these properties of building constructions with software development. We start to believe that the actual construction effort, i.e. programming, is a commodity activity. We start to believe that all programmers are created equal, and that we can easily partition the software construction activity by hiring an army of coders.

Nowhere can we witness more of this prevalent belief than the current offshore trend. As our economy tanked right after the dot-com crash, interestingly it fueled the economy growth on the other side of the world. Now, I am not against either offshoring or outsourcing when done right strategically to enhance the value. What I have issues with is when people seek offshore solutions due to the prospect of "cheaper labor". That is the evidence of the construction metaphor at work, and I believe the buyers will be unpleasantly surprised.

There are always some sort of tensions between "business" and "IT" people. Many business people are great individually, and I know many of them. But birds of the same feathers flock together, and when people congregate together we end up with group-thinks. The business group-think is different from the IT group-think, which causes the tension.

From business people perspective, IT people are problems to be managed. They are expensive, and they speak in Geeklish or Klingeonese. They do not care anything about how to improve the bottom line of business, and even though they stare at the computer all day long, we do not know whether they are playing games or working. If they not reigned in, we might get nothing in return!

From IT people perspective, business people are all stupid like the pointed-hair boss in the Dilbert comic strips. They ask for stupid features and impossible schedules, and they have not a freaking clue about Brooke’s Law - "adding more people to a late project makes it later"! Working for them is no fun, and it will inevitably fail with such bad leaderships. Now we can only brace for the inevitable failure. Perhaps it’s time to dust up resumes again.

Unfortunately for the IT folks, they do not realize that business people has the upper hand in this relationship and can exercise their power.

Unfortunately for the business folks, they realize that they have the upper hand in this relationship and choose to exercise their power.

Because from business perspective, IT folks’ values are just like the construction workers - they are here to get the work done, otherwise they are costs and should be as cheap as possible. Back during the heydays of dot-com era, the cost is stratospheric, and now there are so much more supplies, it’s time to hire the cheap labor to replace all these expensive labors, even if these other people are all the way around the other side of the world. Heck, they can train their own replacements!

The result is… mixed at this time - the jury is still out (from the first and second wave of offshoring). The demand for cheap labor is insatiable, and that is driving up a bubble for these offshore havens. Many of these labor markets are experiencing their own dot-com resource shortage. As demand continues to increase, they will hire more and more unqualified people to fill these demands. However, as demand continue to increase, the newer projects will only get harder and harder, as companies start to warm to all the different possibilities that the vendors have been pitching to them. The demand is bound to drive up the cost to reduce the perceived value, and the difficulty of the newer projects will strain the inexperienced resources’ ability to handle them. At some point, the bubble will burst.

Who will be the biggest losers when that happens?

The ultimate loser in this case will be the businesses. While they can blame the vendors for the failures, they have to look in the mirrors to realize the true reason behind the failure is due to that they have made erroneous business decisions, based on a metaphor that will no longer serve them.

Someone will call my doomsday prediction BS, and that is fine. For the record, I completely hope I am wrong, but only time will tell. After all, dot-com bubble was not the first one, and nor will it be the last. However, the reason for me to write this article is not to talk about the merit of offshore (I will talk about that in a separate article), but rather pointing to the problem of believing a faulty metaphor too literally. If you will not agree with my predictions, at least I hope we agree on the following points from a long term perspective:

1. For both business and technology, the number one success factor is the quality of people
2. For both business and technology, strategy is crucial to long term success, and such decisions cannot be outsourced
3. Business has been and will increasingly depend on its ability to leverage technology to compete and possibly just to survive
4. To ensure business can effectively utilize technology for long term survival is to develop the ability to train and retain the necessary technical talents to jointly make the strategic decisions

In other words, in the not-too-distant future, companies must compete with all they have, and that will include technology. And if you do not have the necessary talents on your team, you are not likely to make the right decisions. While it might seem tempting to go the cheap route right now, building a great working environment for technical people and grow them into the business will enable you to compete with other enlightened companies that are already doing so. That is not something you can outsource.

The challenge for the business people is to realize that in order to achieve such, they will need to understand the basic principles about technology.

One of the top principles to understand is: the software construction metaphor is incorrect!!! Ignore this advice at your business’s peril.

I will explain further about why the metaphor is incorrect in the next post. Stay tuned.