Blog

Welcome to our blog, where we share news related to Sylius and post about technology & eCommerce.

Paweł Jędrzejewski
25.07.2019 | 3 mins read

Technical debt silently throttles your eCommerce revenue

I like eCommerce because it’s very dynamic and it’s easy to notice and measure the technology impact on the business. With more static and non-transactional websites, technical defects can remain unnoticed for weeks or months. They surface when you realize that the sales pipeline is dry.

With eCommerce, a performance defect slips through the manual testing, your website slows down by 200-300ms and your conversion will go down. Checkout is not functioning properly for 2 hours? You will definitely be able to count the broken orders and lost revenue. Sounds familiar? Continue reading to learn if you have accumulated significant Technical Debt.

What is Technical Debt?

It is the sum of all deficiencies in the inner quality of your codebase. The term was coined by Ward Cunningham and I love how elegantly it describes the reality of many software development projects. It’s not as accounting friendly as financial debt (because it’s hard to measure human productivity and lost opportunity) but it’s safe to say that you pay interest in the form of lost development productivity.

Whenever the technical debt grows (and when unmanaged, it grows by default), your development team will need more effort to add your next big idea to the eCommerce website.

Outer (External) Quality

High external quality means that your application does its job now. The banner promoting the latest product discount is appearing for customers from the right countries, the buttons in checkout do what they ought to do. The software is generating money for the business and is reliable.

I am willing to risk saying this: The worst-crafted codebase can reach good-enough external quality with significant effort. The question is: Are you ok with “good enough” and is it the most efficient way to craft bespoke eCommerce applications?

Inner (Internal) Quality

Low internal quality is a bit more subtle and less visible. It can be the silent killer of your project that leads to expensive re-platforming/rewrite. It is all about maintainability, flexibility, understandability and a few other characteristics that are important. It depends on your coding practices, development processes, and quality standard, among other factors.

They Go Together

Yes! “The only way to go fast is to go well”, as Uncle Bob said. In simple words, external quality is about satisfying business expectations, while internal quality determines how fast you can move forward.

You cannot have great external quality long-term if you do not manage your Technical Debt.

How to avoid it?

First, you need to be aware that such phenomena exist in software development. Second, you should have a strategy for:

  1. Minimizing new debt through tools, processes and development culture;
  2. Gradually paying off the existing debt.

The general solution is to be professional about eCommerce project development:

  1. Introduce testing with consideration for the Economy of Tests;
  2. Apply “less is more” in practice and have a rational discussion about each feature. Do you really need it? Ask yourself:
    • Who is benefiting from this feature? Is it an important persona?
    • What is the benefit? Is it real or is it a mere prediction?
    • Is it worth the time? And money?
  3. Repay it with Refactoring but when it makes sense, which means you should not refactor unless the to be refactored component:
    • Needs to change (make small refactorings part of other tasks!);
    • Is changing often;
    • Has proper test coverage (otherwise, write a test first!)
  4. Introduce Static Code Analysis into your development pipeline with a tool like PHPStan;
  5. Be picky about the tools and libraries you use in the project, avoid untested and untestable libraries or frameworks.

Summary

There was much written already about testing and some about Technical Debt but my aim with this blog post is to get the business and tech closer to each other and increase the mutual understanding. I’ve been working with eCommerce development teams for many years now and I see so much potential productivity to be saved with better practices and proper tools.

Technical Debt is as real (just less measurable) as your financial debt, especially if your business relies on the technology. It should be understood not only by developers and CTOs but also by business owners and decision-makers. So make sure to share this article with your team and I hope it inspires a discussion about the practices you use! Or if you have the debt under control already, share your idea in the comments below!

We at Sylius take Technical Debt seriously from the very beginning and proper testing practices and synergy between external and internal quality has saved us numerous times. 

Did you know we completely reworked currency-handling days before the 1st beta release of the product and only thanks to Behat and phpspec we managed to do such pivot so fast and under control?

 

Getting started with Sylius
Online course (8h)

Paweł Jędrzejewski
See my roles

Self-taught developer and entrepreneur, who has built an entire career and business through Open Source technology. Speaker at international conferences. PHPers meetups co-organizer. Keen on helping other young entrepreneurs and companies who may want to follow a similar path.

Be the first to find out about new posts. Join to our newsletter!