A lot of the brouhaha over the duct-tape controversy reminded me of “The Innovator’s Dilemma” which I have mentioned a few times on this blog, but never really elaborated upon. Well, it is like this. People wonder why companies which are market leaders in a segment fail to see competitors surging ahead with better technologies. Usually, people attribute this to arrogance and pigheadedness of the management in those companies.
Clayton Christensen’s research tells a different story. It is not mismanagement, but good management that lead to successful companies being toppled. Market leaders use good management techniques to discover and promote products that have a probability of better market acceptance and hence good sales and profits. While doing so, they discard many products or technologies that do not look promising. While their determination is usually correct, sometimes one of these discards manages to become a better product and surpass the market leader.
The timing here is the critical piece. When a technology is rejected by the market leader, it is inferior to the current technology used by that company. If it wasn’t, it would be poor judgment to reject it. In fact, several such inferior technologies are rejected. And rightly so, because it is impossible to predict which would improve in the future. When you hear about some startup rejected by some company and then going on to make billions, you have to take it in the context of hundreds of such startups that were also rejected and ended up in the deadpool.
Christensen calls the upstart technologies “disruptive” as opposed to “sustaining” technologies which are embraced by the market leader because they have a greater potential for faster results and profits. “Disruptive” technologies may seem primitive or difficult compared to present technologies and although they may have promise, no one is sure if that promise will materialize.
So what does this have to do with coding?
Well, when it comes to coding, there are some tactics that produce instant results. Better hardware, better software tools (IDEs, refactoring tools, etc.), adding another tester, reducing programmer distractions, some refactoring methods, etc. are some examples. Whether you have the money or circumstances to do these is beside the point. No one argues against them theoretically.
But there are other steps that are not so straightforward. One is buying or reusing a component instead of writing it. There is the possibility that the tool may not satisfy some important cases and then you have to rewrite it or write some workarounds. Another example is adopting a newer technology or methodology that is not well understood in the industry or even in your company.
In the second scenario, the right short-term management decision is to stick with what you know and get the job done. This is good management because it avoids risk and ensures that company projections are met.
But, if the company continues to operate in this mode, the sequence of correct short-term management decisions will end up with a long-term disaster for the company. Yes, many rights will create a wrong. This is a case where you need someone to provide long-term leadership.
Here is the long-term problem. Other companies will embrace the newer technologies and methodologies, which might get better over time, and they will use that advantage to leap-frog over your company. Your company will be stuck polishing its skills in the older technologies that no one wants. Even hiring will be difficult because employees do not want to work in such older technologies.
Take a simple example. Let’s say your company knew plain old ASP and continued to build applications in it even though ASP.NET came into the market. In the short-term, it was easier for your employees to build an ASP application than learn ASP.NET and build one, perhaps committing some mistakes that required costly trouble-shooting. In the long-run, your competitors are building similar applications faster with higher quality. Your employees are leaving for those companies and you cannot hire anybody who wants to work with ASP.
Now substitute ASP.NET with all the latest “architecture astronaut” stuff that Spolsky derides.
True leadership would be to set apart time, money and resources to investigate new technologies and ideas constantly. Build pilots and understand migration paths to newer technologies. Learn about the communities around them and how you can get help to obtain workarounds (because there always will be a need for them). Understand what vendors, customers and employees think about where they want to go.
As I talked about before, if someone is showing up at your door suggesting some new idea, the worst thing you can do is write a blog post mocking them. They are telling you something that may be valuable. At the very least, you must invest some time to understand what in the world they are talking about and whether it may make sense for you.
Otherwise, projects tend to become like abandoned houses with weeds growing over the walls. Even if you do nothing, they become outdated and impossible to work with. I know people who are working with technologies that are decades old because there was a good risk-averse manager who couldn’t provide leadership for the long-term.