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 has technical debt affected your company?

Source: https://www.linkedin.com/pulse/technical-debt-can-kill-your-startup-joseph-foster

Has anyone else experienced gross accumulation of technical debt? I'm curious how wide-spread this problem really is.

It's helped my career a lot, cleaning those items up, but I've also seen a good number of start-ups fail or large companies hemorrhage millions of dollars due to adding up technical debt without regard....

...what are some thoughts on experiences with it?

23 Replies

Michael Barnathan
4
0
Michael Barnathan Entrepreneur • Advisor
Co-Founder of The Mountaintop Program, Google Alum
I've seen companies (startups and midsize) fail, or more often, have to rewrite their product and miss opportunities as a result, due to tech debt, often of the sort that wouldn't have taken much longer to do the right way in the first place.

This is in part due to the popularity of feature-driven methods such as the Agile family, which emphasize continually delivering user-visible changes - refactoring and other "grungy" work systematically falls by the wayside unless you're very disciplined. I've seen many nontechnical founders who don't realize that their user-visible features aren't truly "done" yet, or worse, drift from one MVP to another without producing any sort of experience that can truly hit it out of the park for users. (The opposite extreme of trying to absolutely perfect everything before moving on is harmful as well, and will result in software that's always "three weeks away from done" but which never makes it out the door).

I've seen some companies grow to midsize with tech debt - if such a company makes it to that stage, it ends up placing a significant burden not only on tech people, but on support! The harder it is to deliver a great product and fix bugs, the more you'll need to focus on keeping your users happy when they inevitably encounter problems. Better by far to have your product delight users in the first place.

The tech companies I've seen founded by engineers tend to do better in this respect (they do worse in some other respects, so pick your poison).
John Anderson
0
0
John Anderson Entrepreneur
Senior Mobile Developer at Propelics
Just speaking to my own personal experience.

The thing I think about most about Agile is that the goal is to have a potentially shippable product at the end of every sprint. This means that you clean up those things right away that you think that you can do "later on" but later on never happens.

But I can see how many people might put off these items for "later" creating a large amount of technical debt, making the product less than what it should be.

I don't really have a view on how wide-spread this might be in products/startups, but I can certainly say that it's easy to see how developers might incur a large amount of technical debt when these issues should just be dealt with sooner rather than later.
Dirk de Kok
4
0
Dirk de Kok Advisor
Founder and CTO Mobtest
Almost by definition you will accumulate tech debt when moving forward with a startup, as you adapt your product to market demand.

Focus first on product market fit, worry about tech debt later.
Steven Schkolne
3
1
Steven Schkolne Entrepreneur
Computer Scientist on a Mission
That article is dumb, it says tech debt is about putting off building technology. When in reality tech debt is the complexity that accumulates as you grow software.

Good engineers refactor as they grow a product (and sometimes decide to leave krufty code in, carefully weighing the tradeoffs based on their experience). Tech debt accompanies all software products, it is not just prevalent but omnipresent. Just one of those things any good software engineer manages.

And yeah - I dunno what this has to do with government. Whoever wrote that should probably read this: https://hbr.org/1996/01/a-country-is-not-a-company


Michael Barnathan
3
0
Michael Barnathan Entrepreneur • Advisor
Co-Founder of The Mountaintop Program, Google Alum
Accumulation of significant tech debt isn't an inevitable aspect of building complex software. It's a product decision, continually made - do we spend time managing the increased complexity of a new feature, or build features at a more rapid rate and let it grow? Sometimes either is the correct choice.

Think of it as your product's entropy. You can decrease the entropy of an open system, but it takes an input of energy from outside of the system to do it.
Tim Cullen
3
0
Tim Cullen Entrepreneur
Principal Software Engineer
This definition of "Technical Debt" reminds of what I've seen several startups do. Both ones I've worked for and ones I've known other people have worked for. They start out with a prototype, demo it around, get some funding, then try and go forward and make a product out of it. More often than not these prototypes were quick hacks thrown together just to get something to demo. What they should have done was take what they learned from what worked and what didn't with their prototypes and in their demo sessions and started over applying what they learned to a new code base. The usual excuse is "That would take to much time and we need to get something to deliver now!". Then they spend much more time and effort working around problems that arise that could have been fixed correctly from the start.
Robert Gezelter
2
0
Robert Gezelter Entrepreneur
Principal, Robert Gezelter Software Consultant
In many ways, I agree with Tim and Michael.

I have seen many projects, in startups and in established firms, where a "quick and dirty" prototype is done and then an attempt is made to "salvage the existing investment" no matter how crufty the proof of concept is. As Tim has noted, this almost always leads to large amounts of time renovating the existing code, rather than designing a solid implementation from scratch.

In my opinion, Michael's process based perspective also has much to say for it. Sometimes, one does need to hack something temporarily so that progress can continue. The challenge is not losing sight of the fact that the workaround was temporary, and needs to be fixed. This is not only a question of programming, many organizations commit this sin in ways large and small (I remember my first job as a systems programmer, the Computer Center was housed in a "temp" building, for over a decade).

The real danger of technical debt is a side effect of the synergy of both of these causes: one never knows when the debt will be called. A problem which needs correction involves one or more items of technical debt (incompletely thought out features/code). The problem must be corrected quickly, but it also requires that all of the outstanding issues be completely understood. To continue the debt metaphor, it is a margin call or repayment demand. Haste is the enemy of care, and the resulting consequences prove a burden to the organization.

It may be desirable to work quickly, but working too quickly leads to hard to undo defects.
Rob Gropper
4
1
Rob Gropper Entrepreneur
Director at PetHero, SPC - Member at Eastside Incubator - Principal at Tuxedo Technologies Group
Joseph, This is not the place to market your consulting firm...
Yaron Banai
1
0
Yaron Banai Entrepreneur
SW engineer at Ethernity Networks
Technical debt is a serious problem. You always have several milestones before a real product delivery usually in the form of a demo (internal or to customer). In a competitive world these first milestones are challenging themselves, and then you are tempted to do one of two bad things: 1) settle for an unscalable, partial solution, good enough for the demo, 2) put of solving bugs. Having done that you are now tempted to demonstrate additional features putting off the refactoring and bug fix even further. These is in contrast to the agile method- you deliver features incrementally BUT each feature is done with a sound technical solution without leaving the bug fix behind. You deliver product quality feature.

A side note to Shawn Burke - the analogy to government is not at all what the original post is about. When expressing ideas we all have our own analogies. I truly hope that in a professional forum we can relate to the issues of the discussion even if we dislike the analogies used to explain them ...
Aleksey Klempner
1
0
Aleksey Klempner Entrepreneur • Advisor
Entrepreneur, Executive, Angel Investor
A lot of companies have this issue. But good CTO should make the right choices that are beneficial for business and technical team.
Technical debt is not bad if company makes money and you accelerate. If company is not growing and your team is busy fixing issues with existing system it's a cancer and is really depressing :).


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?