First in a four part series. SPEED.
Software development in the world of Ecommerce requires speed. The immediate relationship with the buying public means those who don’t keep up lose out. The balancing act between the demands of the market and the demands of good, durable software development can be very difficult to resolve.
Too often, companies choose between either:
doing the right thing (delivering now), or;
doing the thing right (delivering quality, but late).
Option one will work as a temporary measure. But the cost of prioritizing speed over quality issues will grow over time, up until the point where you have to rebuild your system.
Conscensia prefers not to see this as a binary choice. We see time and again that not doing the thing right long enough will eventually make it impossible to do the right thing. The thing about technical debt is that…. it has to be paid. However, there are ways to incrementally improve underperforming legacy systems. And when they don’t hack it, the option of starting afresh is not only less daunting than it may seem, but brings with it a number of connected upsides that should not be underestimated.
If you don’t want to head down the road to purgatory, the exits are clearly marked. The first sign is early in the journey:
- Should be easily scalable, so it’s easy to extend once new features are planned without a lot of overhead
- Micro services are often a great way to go;
If you’ve already set off, there are two more options that can mitigate the down side of speed:
- Ensure code changes won’t affect related parts of a platform
- Help to reveal issues quickly
- Reduce time needed for testing
- Often a more productive alternative to manual testing
- Good process that cannot be adapted to reality is not much use. When the market calls, you answer. The mistake is not in compromising good practice, it is in not doing this DELIBERATELY. Make an explicit decision to go fast, but also plan the pay back afterwards, just as explicitly
- Code reviews improve code quality and as a result reduce technical debt
- Well-defined processes help to analyse sources of technical debt and correct them during subsequent iterations
For those who are too far down the road, the last but most interesting option still remains:
- Is a great way to reduce (pay back) technical debt
- Although the upfront costs can seem prohibitive, the payback is calculable and manifold
- The cost of not refactoring may be greater than that doing it, but that cost is being paid anyway, so its easy to overlook it
There is a common misconception that correcting the past isn’t much fun. It is. Not only is the investment more than worth it, by addressing legacy issues, you get to monetize your own experience. Literally.
Monetization comes in 2 forms:
- direct cost (time spent*hourly rates) of infrastructural inefficiency and
- opportunity costs saved (unproductive time spent*average income per unit time)
Calculating the first item is not difficult. Estimate the cost of refactoring and amortize it with time saved.
As always, it is the lost opportunities that cost the most. The leverage you get with an efficient system is worth investing in. Time spent not being able to implement is time not spent on implementing. In other words, not doing billable work. Slow and buggy implementation brings another cost: reputation. And it doesn’t stop there. Try scaling quickly (or onboarding not slowly) in a legacy scenario that requires 25% or more overhead in work arounds…. (there are more than you think or anyone would admit).
Our clients come to us for software developers that are handpicked and dedicated exclusively to them. They expect and we provide teams built on processes that are integrated deep into clients’ domains; teams that know and understand our clients’ business vision and can ask the right questions at the right time. We can create an ideal scenario with tailor made processes to get you out of the mud, no matter how deep it is.
+49 152 345 20 507