Starting new projects: why a strong foundation is more important than rushing to market
When creating an entirely new application that fulfills a market need it is tempting to rush it to the market in the never-ending struggle to get there first. As a software developer I am chiefly responsible for writing software that is easy to adapt in the future, and rushing to the market by writing unmaintainable code is entirely at odds with that responsibility.
Sure, rushing to the market gives a temporary benefit, but to me it’s just that, a temporary and rather small benefit. Google was not the first search engine on the market, they were and still are however arguably the best search engine, which is a much stronger advantage. With just a quick peek on wikipedia we can see the search engine that conquered the world improved considerably over time, which much better explains why they are still king in the search engine market. Getting there first is not a magic everlasting advantage, it is a temporary benefit. Being able to continuously improve the product, at a faster pace than the competition, that to me really separates the winners from the losers. How does one obtain that advantage? Not by rushing to the market, but by building the software in a sustainable way, from the ground up.
Foundation to build on
After some lessons learned the hard way, we decided to do all the options that increase maintainability from the start, they are not optional, they are mandatory. To provide the best possible solution to our clients we need to create a foundation for our product that allows us to adapt it easily over time to our ever-changing client needs. Every iteration we want to provide a better software solution than we had the before, forever. This requires a foundation on which a product can easily change over time, which is what we decided to build for our latest projects: real estate registration and iTax. They are both solutions in the real estate market, a market which changes often and changes a lot. To describe how we started we will highlight some elements that allow us to sustainable go to the market:
- QA: automate pragmatically but effectively
- Newest techniques only, even though it requires the team to adapt to new techniques which delays when we’ll get to the market
- Continuous integration from the start, not building any functionality until it can be continuously integrated
Obviously more is required and more steps were taken, but for the sake of brevity we’ll highlight only a few.
The first step: QA
Even though there is nothing to test yet, there is no functionality, it was still the first step we took. Roughly speaking this is what the entire setup would encompass:
Or in other words: it would continuously run automated tests on different levels and measure and monitor how well the test cover the entire product. For this we used several techniques but it was mainly Protractor, Karma, Rest Assured and Junit that were running the tests. Every build runs all the tests so we always get sufficient feedback on whether everything is working as expected, right from the start.
Newest techniques only
Instead of focusing on what the team already knew and hopefully deliver faster with that, we focused on what techniques best suited our long-term commitment of maintainability. We decided to go for roughly the following stack:
Especially on the front-end this meant training our people, at the cost of going fast at the start, but it is well worth it to us.
Continuous integration from the start
Changing anything in the product should always lead to a full build, including compilation, static code analysis and automated tests:
Making sure coverage is high fromt the start and getting static code analysis issues resolved soon helps us deliver continuously great code, which in turn helps us delivere a great product. As a side-note there are more continuous integration parts not shown on this pipeline (such as releasing the product), but the image accurately describes the method.
The paradox is that even though we invest heavily in creating a strong foundation to build the functionality on, which costs more time than building a weak one, we still believe this will lead to being done sooner rather than later. But the main goal is having a great product long-term, which requires the code to be maintainable from inception, immediately and not later. This is exactly what we hoped to achieve by investing considerable time in not building any functionality but a solid base instead.