Big News: FounderDating is joining OneVest to build the largest community for entrepreneurs. Details here
Latest Notifications
You have no recent recommendations.
Name
Title
 
MiniBio
FOLLOW
Title
 Followers
FOLLOW TOPIC

Question goes here

1,300 Followers

  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur
  • Name
    Entrepreneur

How do you handle technical debt?

Like many (all) startups we have technical debt and it's always a tension between fixing it and working on new or existing features. Obviously, if it is perfecting performance we prioritize it but curious to hear how other companies think through it and prioritize fixing it?

20 Replies

Sean Lars Ganser
2
0
Sean Lars Ganser Entrepreneur
CTO / Co-founder of InMoment Software
Tricky territory.

Firstly, the payoff long-term is worth taking care of the technical debt asap. It can be arduous, and your devs might hate you, but you need to do it.

Also, moving forward, a well-engineered codebase that is testable and maintainable will help keep technical debt at bay for future endeavors.

We've been in many situations where we had to just 'leave things be' or code freeze because we've got paying customers, and we can't rock the boat. It's painful, but it's part of the process.

Technology is a journey, there is no perfect, and everything takes time to develop and mature. Your systems will never be ideal or perfect (this goes for all companies, big and small).

Top priorities should be:
Solidify current systems for paying customers.
Consider a refactor.
Test different systems before implementation.

These are expensive and time-consuming, but it's necessary. Sometimes as founders/C-levels we want to move things forward and can't justify our devs testing new systems that won't have a payoff, but it's part of the process.

Be prepared to spend 1-3 months having your team experiment with new things and processes. It's natural.

Unfortunately, in my experience, it's a matter of letting go...
Stephen Salaka
0
5
Stephen Salaka Entrepreneur • Advisor
Product Development Manager at Tsunami Tsolutions LLC.
Thumbscrews for the developers.
Michael Greer
0
0
Michael Greer Advisor
CTO & Co-Founder at TAPP TV
It usually depends on who the decision-maker is. The closer they are to tech (CTO), the more they know the cost of tech debt. The further away, (Product, CEO) the more they will select near-term business goals. As a CTO, I try and make a roadmap that runs through areas of technical debt, so we can address them en-passant. You never get a chance to actually stop and work on it directly. But you *have* to pay this debt as soon as possible, or it will delay releases, create bugs, and deter/disengage good engineers. Hack your way through, and put the refactoring inside new features. You'll never get it approved directly. -Mike
Zohar Hirshfeld
1
0
Zohar Hirshfeld Advisor
Sr. Director Business Operations, Product Globalization and Chief of Staff for Central Engineering
There is not scientific approach to this. I would suggest addressing technical depth in the following cases:
1. Very buggy code which requires constant patches
2. Stable component which from a product perspective is not planned to be modified
3. A centralized component which is planned to be used/shared by multiple components
4. This is probably a significant one: a component or piece of code which can only be patched/modified by a single person in the company (single point of failure).

I might be missing more reasons, but those are the fist that come in mind.

Cheers!
Rob Mitchell
1
0
Rob Mitchell Entrepreneur
Senior Java Software Engineer at Direct Commerce
There's a slew of both business and technical variables when talking the dreaded "tech debt" challenge. The fact that you're talking about it is a good indication that everyone's on-board with its realizations.

My $0.02 as a long-time engineer and now software manager:
* keep the talking, diagramming, and/or some level of measurement going
* tech debt is not "all" bad
* based on your company's age and revenue's, the younger/smaller you are, the more you should focus on customer and revenue generation; otherwise always to to whittle-away at some tech debt in the context of feature development
* if you can, devote 2-solid days for the entire business and/or tech teams to work collaboratively and solve tech debt (or, conversely, add to the tech debt if its too low and you can get a huge ROI but adding to it)

Got specifics? Feel free to share.

Thx
-Rob



Mike Taylor
1
0
Mike Taylor Entrepreneur
Web Developer
Can someone define technical debt? I think that it often relies on the technical lead to identify the code that is determined to be technical debt, which can also yield varying opinions.


I'd say first and foremost, if you want to start with paying down technical debt, and you have no test suite, start writing writing tests.

0
0
X
Entrepreneur
If you have a dark basement where your developers do not want to go, you should consider that a priority. Performance is one thing but stability and maintainability are way more important factors.

As soon as we have a feature which needs to be implemented but takes longer than expected because of tech debt, we prioritize tech debt over features.

Also, we have a lot of discussion when it comes to new features. A new feature usually means that we can scrap an old one. Just a matter of business value
Tom Maiaroto
3
0
Tom Maiaroto Entrepreneur • Advisor
Full Stack Consultant
I think too many people underestimate the impact of technical debt. I hear some people say, "That's not why startups fail." I agree, it's not the "sole reason" -- but it is almost always a factor. Whether you realize it or not.

For example: You might say, "Well there was no product/market fit." Ok...But if your technical debt was smaller, you might have been able to find that fit or pivot easier.

It has a profound affect on a company and can also make the difference of having a healthy profit margin. Technical debt quite often leads to increased overhead and if that plus the CTA is not lower than the LTV of customers...You're toast. Your business can't scale without fixing something.

So at that point, yes. You must fix technical debt because it may not be an option to fix something else. However, if you can lower your CTA, you may wish to focus on that before the technical debt because it may be easier and cheaper to address.

Fixing technical debt is expensive. Perhaps one of the most expensive work efforts out there.

Here's an approach I've seen have quite a bit of success: Get your core team (which is going to be the more expensive resources) to define the problems first. Get a good handle on what needs to change, why, and put together a plan. Then utilize the cheaper resources you may already have or outsource new resources to execute on that plan and remove some of the debt.

This allows you to bucket the work and do it in phases. Which helps fit any budget. Especially if contracting out the work...Because otherwise you're paying salaried employees to do it and you can't just stop when you want. Pssst, this helps prevent layoffs.

That's how I'd repay technical debt on a budget to be frank. I'd simply outsource it. I do believe it's a problem that can be outsourced too...But only after properly identifying it and coming up with a game plan. You need absolutely clear instructions when outsourcing.

For example: "Refactor this code to do x, y, and z. Removing a, b, and c which are no longer needed. Then update some test cases and write new ones for the new stuff." It could be as simple as that.

This way, your core team is able to focus on new features and maintaining the current product and UX.

Hiring new resources requires a ramp up period. They need to learn the product, the roadmap, etc. So the best resources to further the product is those who are already intimately familiar with it.

This means the cost of adding a new feature is (usually, but not always) lower than it would be if you had existing resources clean up technical debt and hired new resources to build new features.

Using new resources to build new features is most likely only going to increase your technical debt.

New resources need to learn the product and one of the best ways to do that is by cleaning up that technical debt. This is because it can be done in pieces and it gives someone a good overview of the product and window into the past. It clearly shows developers what was tried and what didn't work and what now needs to happen.

THEN if you want those new resources to work on the future of the product, you could do so without accruing as much technical debt.

Though one thing to keep in mind is that you always accrue technical debt. There is no such thing as a technical debt free product. I think the most important thing of all is to understand when you need to repay it. Even if you aren't efficient in repaying it.

Kevin Tureski
2
0
Kevin Tureski Entrepreneur
VP Products at Fabric Software Inc
I provided a fair bit of feedback on the Technical Debt chapter of Kenny Rubin's "Essential Scrum" and am currently with a startup. My views are pretty much unchanged: Flag it and set aside time to address it or else. If you need a prototype to demonstrate your unique value, accrue as much technical debt as is required BUT realize that you will need later need to refactor large parts of it before putting that code into production or a paying customer's hands AND reserve that time as part of the next phase / milestone etc. Fail to do that, and you'll soon be on your way to your next startup. If you are building a framework that will become the basis of your product, then near-zero tolerance is a good place to start. I say near-zero since there are exceptions such as adding this feature will land / keep this client allowing us to meet payroll and refactor soon after. Kevin
Mutinda Boniface
0
1
Mutinda Boniface Entrepreneur
Software Developer | Entrepreneur
Well, technical debt should first be fixed then move forward and work on new features
Join FounderDating to participate in the discussion
Nothing gets posted to LinkedIn and your information will not be shared.

Just a few more details please.

DO: Start a discussion, share a resource, or ask a question related to entrepreneurship.
DON'T: Post about prohibited topics such as recruiting, cofounder wanted, check out my product
or feedback on the FD site (you can send this to us directly info@founderdating.com).
See the Community Code of Conduct for more details.

Title

Give your question or discussion topic a great title, make it catchy and succinct.

Details

Make sure what you're about to say is specific and relevant - you'll get better responses.

Topics

Tag your discussion so you get more relevant responses.

Question goes here

1,300 Followers

  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
  • Name
    Details
Know someone who should answer this question? Enter their email below
Stay current and follow these discussion topics?