5 Steps to Improve Your Time-to-Market

Coldrift uses a proven methodology by means of which it manages to achieve exceptional time-to-market: Software Growth Hacking. There is a direct connection with growth hacking in marketing, yet it requires a lot more explanation.

Below are 5 tips for Software Growth Hacking that will help you to improve your time-to-market:

1. Attack the most difficult area first

This tip is mainly related to managing your energy. Simply, the less difficult the next problem in line is, the more achievable to whole project looks. If you identify and attack the problems in reverse order of difficulty, it will be psychologically easier for you to complete the project. Indeed, skiing down the slope is much easier than climbing occasionally.

2. Defragment your work

Make sure pieces of your work are bundled up together and not fragmented. The higher is the fragmentation of your work, the higher are the switching costs.

3. Trade dependencies and own implementation

It's good to reuse code. Even better if it is someone else's opensource code. But not so good. Dependencies bring risk. Maintaining dependencies is a liability.

So, if you bring a dependency into your project, you instantly get ahead, but the very same moment you create a liability for yourself. The alternative of not having a dependency is to make your own implementation of what the dependency implements. Then it nicely integrates with your own codebase, but you are redoing an effort that somebody has already invested into solving a part of a problem that you are trying to solve. Then people say that you are "reinventing the wheel".

However, being an experienced software engineers, we're confident in reimplementing certain functionalities that engineers with average experience would always take from dependencies. We do that if it allows better control of the code base, higher adaptability and ultimately more qualitative code. In that sense, making your own implementation versus taking in a dependency must be seen as manageable alternatives, especially because you must like implementing things from scratch if you're a good software engineer.

Taking into consideration all the above, an efficient Software Growth Hacking tactic would be to take in a dependency if it has very good fit with your code base, otherwise considering an effort of making own implementation. If that effort is reasonably small, an own implementation is better than bringing in a dependency.

4. Axiomatize of your subject area

Do you like puzzles? They say, software engineering is about solving puzzles… In fact, a lot of people flood into IT because they think IT and computer science is about "solving puzzles".

Well, it is, when your subject area is already axiomatized. Namely, a set of very basic rules is defined upon which further developments are made.

See, "solving puzzles", being a formal approach, is only applicable to formal systems. In the absence of a formal system it's not about "solving puzzles" anymore. To get there somebody must create a formal system for you, such that you can start "solving puzzles". Some sets of axioms are better than others, because they make it possible to describe more functionality in your system in simpler ways.

So, when a project begins somebody must make a decision about how the requirements and the system will be axiomatized. The choice of axioms influences the complexity of implementing certain solution.

This choice is totally heuristic: the success of this choice totally depends on your experience and creativity. Thus, if you spend time experimenting with the basic design choices, you increase your chances of significantly reducing the complexity of the project.

5. Simplify to a reasonable degree

Simplify. Period. Simple solutions are more reliable and easier to implement. Spending time on finding an elegant solution to a problem pays back in the long term and saves a lot of development and maintenance hours. The reason for that is because in complex solutions parts have a tendency to intertwine. Even if you are able to predict the behaviour of each individual part, cooperation of multiple parts might create unpredictable glitches and lead to unpredictable outcomes.

These kind of problems need to be investigated and worked out and the more complex is the system the bigger is this investment.A lot of software projects failed because they tried to implement seemingly necessary complexity. The challenge is: it takes a genius to make simple something that is very complex.