There's no ZitaFTP Server release this week, because last week I was busy paying down some technical debt instead of making progress.

Click here to watch the video on Odysee.

What is Technical Debt?

It's a business/entrepreneur term for what builds up when you prioritize speed over good design and engineering. For example, you cut corners to get something working and out of the door fast, knowing full well that it's going to come back to bite you later. Or, a design decision you made earlier no longer makes sense (e.g., requirements have changed), but you decide to keep plowing ahead without fixing it.

Like financial debt, technical debt has to be paid off later, in the form of refactoring/redesign work. It also costs more and more the bigger the debt gets, and the longer you wait before paying it off.

Why Accumulate Technical Debt? Isn't it Bad?

The engineer in me screams "don't do it! Design things properly." Technical debt is a pain in the butt to deal with. It costs time, money and effort to fix, and all that rework is a waste.

At this point my inner entrepreneur pipes up. It points out that the absolute biggest waste would be to perfectly engineer a product that nobody needs or wants. All that time and effort going into a product or service that nobody uses...

New ventures are filled with uncertainty. You have no idea if people want what you're creating, or are willing to pay for it. So, it makes sense to initially prioritize speed, so you get a Minimum Viable Product (MVP) out as soon as possible. The feedback you get will tell you whether it's worth putting more effort in, and also if you need to tweak your plans in order to find what's called product-market fit.

When Should I Pay Down Technical Debt?

There's no easy answer, because it depends on too many factors. Experience and gut feeling will tell you. That said, here are a few simple pointers:

  1. If your MVP isn't out yet, then err (strongly) toward speed. This is because you have no idea yet if anyone wants what you're making. It's far better to have to throw away a small proof-of-concept than years of work...
  2. Still err toward speed if you don't have product-market fit. Product-market fit means that you've designed a product that there's a market need for, and customers are lining up to buy. You still don't know if you have something that will be a business success, so you want to find that out ASAP
  3. However, if the technical debt lies in the core of your design and everything else is built on top, then err toward paying down the technical debt. The more you build on top of a flawed core design, the more expensive it gets to fix. This is true with any technical debt, but especially for anything at the foundations
  4. Err toward paying off technical debt when you have product-market fit and are getting ready to scale up your business. By this time you'll be profitable, so you can afford to spend time and money fixing stuff. Also, poor design makes fixing bugs and adding new features difficult, which in turn makes scaling up hard. So pay down the technical debt, and get ready to scale your business and serve more people

Notice how I say "err toward" instead of "definitely do." That's because it depends on your goals and particular situation. In ZitaFTP's case, it was item 3 above that triggered the refactoring. The HTTP request API was rather unwieldy. It had too many function parameters, and I've been meaning to fix it for a while. In the meantime I was adding more and more request handlers (e.g., the server settings page has its own handler). I decided that I had better fix this before I create any more HTTP request handlers. Otherwise there would be even more code that would have to be reworked...

Did I make the right decision? I think so, although while I was refactoring the code I wished that I'd done it sooner. Either way, it's delayed the current release, but I'm better off now.