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.
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.
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?
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.
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.
First, you need to be aware that such phenomena exist in software development. Second, you should have a strategy for:
The general solution is to be professional about eCommerce project development:
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?
