3 ms·

> What were small, scrappy companies in 2010/2011 are now either dead or medium sized companies with mounds of poorly documented, idiosyncratic technical debt —

> What were small, scrappy companies in 2010/2011 are now either dead or medium sized companies with mounds of poorly documented, idiosyncratic technical debt — the apparent cost of ninjas and rockstars. This is somewhat of an aside to what the article mainly talks about, but I don't really know that all of this has to do with the engineers vs the companies. Today's scrappy and small companies are still trying to find fit fast, and still have to be tactical. They can't avoid a pile of tech debt because they don't yet know what they need to build. Building a really fancy solution to a problem and then having that problem change out from under you is just another kind of tech debt. So even without a focus on "rock stars", how can you avoid tech debt when you're in an exploratory phase? Seems a bit of an instance of a common way for slightly-less-young-companies to shoot themselves in the foot. If your tech debt is just due to those other people who screwed up when building the initial systems, then of course it's a good idea to rewrite the world!

deleted 7y ago
[deleted]
peterwwillis 7y ago
> how can you avoid tech debt when you're in an exploratory phase? The tech debt becomes welfare if its whole purpose is to be a temporary benefit until eventually getting off of it. Abandon the old one and don't pay back the debt. But don't let zombie pets follow you to the next one... Legacy can be incredibly difficult to kill.
- war1025 7y ago
  > "We have to upgrade right now because everything is on fire!", I don't know exactly how it relates to the broader "tech debt" discussion, but one thing that can make a big difference is to design systems in such a way that there are obvious strain indicators. To quote Firefly, ways the system can "let you know she's hurting before she keels.". How exactly you do that depends on what you're building, but I think it's a worthwhile thing to keep in mind. Can't think of any specific example off the top of my head, but I've noticed that lots of places talk about needing people to be "on call" all the time. We are a very small shop with some fairly high profile clients, and "everything's on fire" situations happen maybe once every year or two. And are then mitigated by fixing the code in such a way that there are diagnostics to let us know if we're ending up in dangerous territory again. Before everything goes Kaboom.
  - peterwwillis 7y ago
    With DevOps you monitor [at least] four metrics: lead time for changes, deployment frequency, mean time to recover/restore service, and change failure rate. These indicators show if you're improving, stagnating, or straining. You can also track more specific service level indicators, the amount of toil to project work, and tech debt versus feature backlogs. The "everything's on fire" metaphor also has a larger context. Sure, when people are getting woken up in the middle of the night because the site is down, shit's on fire. But also "we're constantly missing our deadlines" is shit's on fire, "our customers are not satisfied" is shit's on fire, "our overhead is way too high for what we're delivering" is shit's on fire. If you're out on the water and building a new boat because yours is on fire, it's a little late.
    - war1025 7y ago
      I think we're both saying basically the same thing. So I agree.
  - noobiemcfoob 7y ago
    My experience echoes yours. We had 2 senior devs and 1 junior. We had one major event in 3 years -- a long weekend where things were on fire with code being updated on the half hour. But afterwards, we had so many indicators of when things were even approaching that level the job got almost boringly simple afterwards.

deleted 7y ago

[deleted]

peterwwillis 7y ago

> how can you avoid tech debt when you're in an exploratory phase? The tech debt becomes welfare if its whole purpose is to be a temporary benefit until eventually getting off of it. Abandon the old one and don't pay back the debt. But don't let zombie pets follow you to the next one... Legacy can be incredibly difficult to kill.

war1025 7y ago
> "We have to upgrade right now because everything is on fire!", I don't know exactly how it relates to the broader "tech debt" discussion, but one thing that can make a big difference is to design systems in such a way that there are obvious strain indicators. To quote Firefly, ways the system can "let you know she's hurting before she keels.". How exactly you do that depends on what you're building, but I think it's a worthwhile thing to keep in mind. Can't think of any specific example off the top of my head, but I've noticed that lots of places talk about needing people to be "on call" all the time. We are a very small shop with some fairly high profile clients, and "everything's on fire" situations happen maybe once every year or two. And are then mitigated by fixing the code in such a way that there are diagnostics to let us know if we're ending up in dangerous territory again. Before everything goes Kaboom.
- peterwwillis 7y ago
  With DevOps you monitor [at least] four metrics: lead time for changes, deployment frequency, mean time to recover/restore service, and change failure rate. These indicators show if you're improving, stagnating, or straining. You can also track more specific service level indicators, the amount of toil to project work, and tech debt versus feature backlogs. The "everything's on fire" metaphor also has a larger context. Sure, when people are getting woken up in the middle of the night because the site is down, shit's on fire. But also "we're constantly missing our deadlines" is shit's on fire, "our customers are not satisfied" is shit's on fire, "our overhead is way too high for what we're delivering" is shit's on fire. If you're out on the water and building a new boat because yours is on fire, it's a little late.
  - war1025 7y ago
    I think we're both saying basically the same thing. So I agree.
- noobiemcfoob 7y ago
  My experience echoes yours. We had 2 senior devs and 1 junior. We had one major event in 3 years -- a long weekend where things were on fire with code being updated on the half hour. But afterwards, we had so many indicators of when things were even approaching that level the job got almost boringly simple afterwards.