most engineers probably don’t understand the extent to which “tech debt” works as an abstraction
there’s absolutely “good tech debt”, and it’s not always obvious which you’re dealing with
if you’re green fielding an app, you should expect to launch with some amount of tech debt
most engineers probably don’t understand the extent to which “tech debt” work...
View original thread
35
1
for greenfield, if it doesn’t help reduce time to market, it’s bad tech debt
there’s also some tech debt that you never pay. i think that’s one of the areas AI does worst at, they’ll add reliability in places that it just doesn’t move the needle
there’s also some tech debt that you never pay. i think that’s one of the areas AI does worst at, they’ll add reliability in places that it just doesn’t move the needle
12
1
imo there’s a bit of a specialty in building greenfield. it’s dramatically different from owning mature products
for the latter, tech debt is almost always a bad thing
for the latter, tech debt is almost always a bad thing
9
if you’re truly building greenfield, monitoring is actually one of the most important things, but is usually left out
if you don’t yet understand how users use the product (i.e. its greenfield), monitoring is the strongest tool to building PMF fast. absolutely not worth the debt of leaving it out
if you don’t yet understand how users use the product (i.e. its greenfield), monitoring is the strongest tool to building PMF fast. absolutely not worth the debt of leaving it out
12
i haven’t worked in research, but i imagine research code is the same, but instead of “time to market” you use a different metric, like maybe time to in/validated hypothesis
(which, actually there’s a lot of overlap there with greenfield apps)
(which, actually there’s a lot of overlap there with greenfield apps)
5