Takt Time - How to pick the right technology stack

What’s takt time and why should you care about it?

Every time we start a new project, a startup or even a little app, we are faced with a big decision: which technology we should use. Usually, we programmers choose our infrastructure, frameworks and programming languages (tech stack) based on what we think will make ourselves happier. However, that selection approach based on feeling may not result in the most assertive decision.

In these important moments we should take into account the concept of takt time. Takt time is a discipline used mostly in production engineering and it’s defined as the time frame between the conception of a product and its delivery, that is, it’s calculated taking into account all the time needed to conceive, develop and deliver a product. In software engineering we use this same concept to describe the time between a specification and a production deployment. The smaller the takt time is, the better.

We should be very careful when defining takt time to avoid confusing it with “time to market”. Even though they both tend to have the same value in the beginning, they soon start to differ based on how much investment a project receives; and usually when you invest time in automation and planning, you tend to increase a little bit your time to market but reduce your long-term takt time. Software takt time is mainly influenced by the task itself (complex tasks tend to have higher takt time) and by programmers’ productivity. I’m not going to talk about the first topic because task complexity is big enough to have its own post. I’ll focus more on how to increase programmers’ productivity and, of course, how to keep it high.

So, if you want to reduce takt time you will need to invest in a tech stack that favours fast build, fast deployment and that will motivate you and your colleague programmers to do the job faster, i.e., a tech stack fun to work with.

How to pick the right stack

In my opinion, the first thing that you should do to select the right stack is to keep your emotions aside. If you really want to choose the right stack to work with, i.e., the stack that will make your project more likely to succeed, you cannot get attached to your emotions or to what you have done before. If you want to pick the right stack, you need to know that there’s no silver bullet and that you won’t be able to do it right today just because you did it yesterday. So, forget about your past experiences and your emotional attachment to languages and frameworks.

1) Benchmark your industry

The first thing that you should do is benchmark your own industry. If you are working for an e-commerce business you need to check and compare what other such companies are doing, investing and using. You can do this by reading papers, searching for common tech stacks and looking for opportunities to connect with programmers that work for those companies. One easy way to connect is going to tech events like TDC, QCon, Meetups and so on. There you can meet and share experiences. You have to always keep in mind that the whole tech industry is looking for solutions to reduce attrition and increase speed, so you can use that knowledge to advance with less effort. If you know that all fintechs are moving towards functional languages (Clojure, Scala, F#, Elixir or even Go) you would be better off betting on these techs instead of going with the old plain Java. Another good way to benchmark is through open source. Github has a lot of open repos that you can check to compare languages and frameworks.

2) Plan, innovate and invest more than you think you should

You may think that if you pick a famous and common language like Java (with Spring) you won’t be wrong. Of course, it’s easier and safer to pick a famous language and/or framework because you will probably have more (and cheaper) professionals and more online available content. However, in the present times, if we want to reduce our takt time, we need to invest in our tech stack. And, please, don’t get me wrong, when I say invest, I’m not saying that your company needs to have an R&D department or that you need to stop doing your current job or, even worse, that you need to create your own programming language. When I say invest, I mean more everything that will delay your instant result and create an asset that could improve and maintain your future productivity. Investing means the time you will spend thinking about your architecture before start programming. Yes. I’m talking about that time you know you should invest planning before doing. Investing in a tech stack means selecting the right tool for the job. It may sound a little cliché and obvious, but that’s not it. Investing means stepping out of our JVM’s comfort zone and trying a new approach using Python or Ruby or Go. I’ve seen a lot of teams avoiding new technologies, frameworks or process because they don’t want to learn something new or because they are too afraid to try it, or both. You need to reserve (invest) some time to make some Proof of Concept. And, after that, you need to try this new technology. Furthermore, you need to do this tech change knowing that you’ll be slower in the short term, but faster (with lower takt time) in the long term.

Conclusion

In the end, the conclusion is very simple and obvious. You need be aware of what tech stack your industry is using and be brave to try it. The most important thing to know is that you will need some courage to try this new feature and even more courage to say no to unrealistic deadlines. If you want to pick the right stack, you need to invest time in PoC, Innovations, new languages. However, always keep in mind the goal of it all, which is to reduce your takt time.

And I almost forgot, If you are feeling braver now, how about trying a new language? How about Go? CLICK HERE to see how to start coding right now.

• development
• technology
• stack