Monthly Archives: December 2012

If you want to your company to provide the best customer support in whatever industry you are in, you should build your own tools and put them in the hands of your customer supporting personal.

Figure out what you want to be the best at and build your optimal solution for this specific purpose. Use and integrate with Commercial-Off-The-Shelf COTS tools for parts of the business which should be standardized or which cannot differentiate you from your competitors.


The technology which is available these days to produce custom solutions is extremely powerful and well established. Cloud services and providers together with open source technologies provide a application development platform which can be used to make what you want very quickly in a capacity which fits your requirements – no problem.

The decision about “Build vs. Buy” should not be about about “Time to Market”. If you want “Time to Market” standardize the way you build and bring products to the market. Take Amazon AWS as an example. It blows my mind, every time Amazon brings out a new service fully integrated into it’s product portfolio.

With the today’s changed technology landscape, the time which it takes to bring a custom solution into operation becomes limited by whether you can formulate what you want well enough to implement – not whether you can implement. Time to market of custom solutions is bounded not anymore by development time, but by requirement eliciting time.


I learn something new every day. I have to learn constantly to keep up with relentlessly fast changing IT world. I also forget most things i’ve learned – to conserve the finite amount of developer memory i have – but this is not the point.  I find that i have only really understood something if i’ve gone through the “understanding dip”. Most of the time, when i believe that i’ve understood something initially, i find out that i actually haven’t. At least my subjective feeling that i’ve understood something is initially quite well. This is sufficient most of the time because most of the time you’re not entirely wrong, just not really correct ( and most of the time your peers are none the wiser because we’re talking about non trivial subject matters here). Upon more thorough learning, i tend to go though a “dip” which is the feeling that you understand less than before. Eventually through intensive study which requires time for reflection, you can come out of the dip with a better understanding than before – wiser than before. If i’m studying something and have not had this “dip” feeling, i don’t trust that i’ve fully understood the subject.

Most of the time, IT practitioners today don’t have the time to ride the full learning curve all the way to the end. By the time you’ve learned something ( gone some way up that curve), the next thing is knocking on the door and you start on the next curve. The learning curve is more often related to developer “productivity” than to “understanding”. If you cheat and skip off the “learning curve”, you’re productivity suffers. If you don’t ride the “understanding dip” to the end, you’re likely to be simply wrong about a lot of the things you think you know about – which is potentially a lot worse.