About time to market

Cover image

About Time to market

Each time I think about it, I get mad ;-D. During the last twenty years of fields experience, in different markets, one of the problems that I faced many times with the development teams of which I was part of, is time management. Frameworks like SCRUM tend to increase throughput forcing us to focus more and more on the delivery, being pragmatic and planning in the short time makes us tighten the time to market, becoming more predictable and profitable. All this is true if it's made in the right way (all together: c'mon aim at that profit margin, please).

Working alone, I know, can be overwhelming and can be less prone to apply a perfectly structured SCRUM approach, in these cases, pragmatism comes to help. Barebones empiricism, the one my grandma would have introduced like "Talk some sense into yourself", the one which makes us the ultimate Google-fu practising and, in the end, the one we use to find the better porn in the web, we all have it, right?

The first question we must ask ourselves, when we face any task, must always be: "Can it be done faster?", search, study, give yourself the time to do it and not in the indefinite sense that seems to have this sentence, but really focused: fix a defined amount of time to answer THE QUESTION, without slumping or exagerating, but do it and then, make this know-how it into a self contained component (library, gem, pip, etc.), which you will surely use very often in future projects.

Observation over many years of work has led me to identify two methods (and two problems, that's the ongoing dualism):

  1. the ones which, given a project, start coding without a question, completely focused on the delivery, writing a lot of code.
  2. the ones which, ask themselves THE QUESTION, but never fix a timeframe.

Both will fail, one because will develop a non-modular solution, the other one because he is still there looking for perfection. Don't be perfect, be pragmatic and get help from existing resources that can be integrated into your project, you could learn a lot, really.

Let's keep it in mind, especially if you develop custom solutions: let's not get lost. Each custom development project will make you surely face technologies that you do not know, set a precise time, that with experience will be evaluated better and better and then take that time, the one to look for solutions on github, gitlab or stackoverflow. They are friendly platforms and every time you have to do something new, ask yourself if it could be already done before, make this approach our own, make THE QUESTION part of you and do yourself a favor, do not start to develop by reinventing the wheel, I know we all do it, it is a primordial instinct, like for the lemmings, but, please, stop your desire to jump off the cliff. Look around, giving you a precise time to do it and you will see that later you can launch yourself from the same cliff with more awareness, maybe with that friendly parachute found in the flight school on the next cliff. It will make the your landing less tiring, painful and, well, splatter. And we know it, a splattered software is like a zombie: it's really scary, especially when it's up to you to dig it up and work on it again.

Now, in addition to having reached a more predictable time to market, you also have healthier approach to development, but all at two conditions: the application of THE QUESTION and giving a fixed time. This must become a mantra that goes off automatically. As soon as you are asked if you know how to do something, no matter how small, the Question&Effort pair is also a best practice needed for the development of quality applications.