So true!
Tag Archives: Strategy
My Problem with Conventional Wisdom
More and more I have realized over the last few years that I have a really big problem with many positions that are considered “conventional wisdom” or best-practice. And this goes for a wide variety of topics: software development (which I consider my main competency), technology as a whole, management, career planning, strategy, etc.
In the areas where I have developed a high level of expertise it has been clear for the longest time, because there I could easily see what conventional wisdom usually is: An oversimplified version of the true matter, that anybody can talk about assertively after having spent one or two hours with it. It is a bit like at university when after a 90 minute lecture some people really think they now understand what normalization in the context of the relational data model means.
But in reality the conventional wisdom is usually the lowest common denominator, and that only for a specific context. If you understand this and take it as a starting point for a real discussion, that is fine. But never fool yourself and think you have understood the topic. Unfortunately, this is a somewhat unpopular position and many people are offended by the mere suggestion that something is more complex than they thought so far.
What makes this a problem is when you combine it with another conventional wisdom: “Any decision is better than no decision.” Really? I think it is downright stupid. Of course, one should avoid what is called analysis paralysis and define a threshold for when a decision needs to be made. But all too often it is just an excuse to make a decision without having the slightest clue what its consequences are. Or to quote Herodotus (484-452 BC): “Quidquid agis prudenter agas et respice finem” – whatever you do, do it wisely and consider the end.
Back to the actual topic: Assuming that conventional wisdom comes into being roughly the same way for all subjects, this also means that you should stop accepting it for things you don’t know much about. Think of it as a news clip-version of something really complex. It is probably not completely wrong, but certainly an extremely limited version of the true matter. If you want to understand things, you need to dig deeper.
When looking at this from a strategic point of view, conventional wisdom in many cases means the same as commodity. If you are a product company (and that includes software) going for what everybody else does, will not help. Rather, you should spend some time thinking what you want to do really well. Believe me, it is not convincing when you interview four vendors and they all tell you more or less the same. All you know after such talks is that none of them really has a grasp of the business they are in.
Conventional wisdom will allow you to play it safe in terms of office politics, but not in terms of market success. Is that what you want?
Simon Sinek: The Finite and Infinite Games of Leadership
Another very interesting talk of Simon Sinek, this time at Google. The full title is
“The Finite and Infinite Games of Leadership: Leadership, Business and Finding Purpose in the Workplace.”
The following points were interesting for me:
- Time code 7:00 : Infinite players do not compete with the competition but themselves. This has an awful lot of strategic implications.
- Time code 16:55 : Dealing with personal objectives and bonuses. Also see my post about this very topic.
- Time code 33:00 : Why are small companies usually more innovative than big ones?
Choosing a Technology
I recently started a new hobby project (it is still in stealth mode, so no details yet) and went through the exercise to really carefully think about what technology to use for it. On a very high level the requirements are fairly standard: Web UI, persistence layer, API focus, cross-platform, cloud-ready, continuous delivery, test automation, logging, user and role management, and all the other things.
Initially I was wondering about the programming language, but quickly settled for Java. I have reasonable experience with other languages, but Java is definitely where most of my knowledge lies these days. So much for the easy part, because the next question proved to be “slightly” more difficult to answer.
Looking at my requirements it was obvious that developing everything from the ground up would be nonsense. The world does not need yet another persistence framework and I would not see any tangible result for years to come, thus loosing interest too soon. So I started looking around and first went to Spring. There is a plethora of tutorials out there and they show impressive results really quickly. Java EE was not really on my screen then, probably because I still hear some former colleagues complain about J2EE 1.4 in the back of my mind. More importantly, though, my concern was more with agility (Spring) over standards (JEE). My perception with too many Java standards is that they never outgrow infancy, simply because they lack adoption in the real world. On the other hand Spring was created to solve real-world problems in the first place.
But then, when answering a colleague’s question about something totally different, I made the following statement:
I tend to avoid convenience layers, unless I am 100% certain that they can cope with all future requirements.
All to often I have seen that some first quick results were paid for later, when the framework proved not to be flexible enough (I call this the 4GL trap). So this cautioned myself and I more or less went back to the drawing board: What are the driving questions for technology selection?
- Requirements: At the beginning of any non-trivial software project the requirements are never understood in detail. So unless your project falls into a specific category, for which there is proven standard set of technology, you must keep your options open.
- Future proof: This is a bit like crystal ball gazing, but you can limit the risks. The chances are bigger that a tier-3 Apache project dies than an established (!) Java standard to disappear. And of course this means that any somewhat new and fancy piece must undergo extreme scrutiny before selecting it; and you better have a migration strategy, just in case.
- Body of knowledge: Sooner or later you will need help, because the documentation (you had checked what is available, right?) does not cover it. Having a wealth of information available, typically by means of your favorite search engine, will make all the difference. Of course proper commercial support from a vendor is also critical for non-hobby projects.
- Environment: Related to the last aspect is how the “landscape” surrounding your project looks like. This entails technology but even more importantly the organization which has evolved around that technology. The synergies from staying with what is established will often outweigh the benefits that something new might have when looked at in isolation.
On a strategic level these are the critical questions in my opinion. Yes, there are quite a few others, but they are more concerned with specifics.