Continuous Learning

Do you know who the Dot Com Mogul is?

The first time I came across John Chow Dot Com was through his Google ads on Steve Pavlina’s amazing self-development site. I had been surfing the web for a long time, and could ignore ads very readily, but I could not ignore this one. The ad read

I wondered, “who takes out an ad just to tell people how much they love someone else’s work?” My curiosity got the best of me, and I decided to check it out. What I found was a world that I did not know existed before - the wonderful internet marketing world. I was like Alice following the white rabbit, and found a whole other existence that I could not have fathomed out of my mind.

Now, I am no stranger to a different part of the internet - the technology side, having spent a decade learning and perfecting various technical and management disciplines, delivering sophisticated systems for companies like Microsoft. Naturally but erroneously I think I know a lot about internet. Marketing has always been a second thought for me, even though I realize the principles behind marketing is important, I believe I can integrate marketing into my product and that will be the end of the story. Boy was I wrong. Marketing is HARD.

Back in July I started my Leaderware List wanting to promote a different way to think about software development, and I was betting that the quality of the content will speak for itself and the word of mouth will automatically spread. Of course that did not happen, even though people were telling me the content is good. That left me scratches my head - if you build it, why won’t they come? That was a wake up call for me that there is a lot more to learn about marketing and promotion, and simply having a good content is not enough. People must know about your product.

The light bulb went off in my head when I discovered in John Chow Dot Com - Keep reading →

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: Keep reading →