I found this newsletter really interesting - specifically, that Evernote is stomping on the breaks until they've cleared up all of their tech debt.
In my experience (and in disagreement with the author) tech debt is inevitable - it's not the consequence of "suboptimal code" and "taking shortcuts" but rather the consequence of business requirements evolving beyond the system's architecture.
There's a delicate balance in the right amount of "technical leverage." It's very easy to grind to a halt over-engineering a system for all possible future requirements (some of which may never be needed!). On the other hand, it's easy to architect a system too shortsightedly such that any modification is difficult to do.
The best approach I've seen from technical leaders is to use new feature sets/initiatives that come from the business as an opportunity to clear up technical debt in the process. That way, you can guarantee that the architectural direction you're taking is aligned with business needs and that you're not wasting time on unnecessary improvements.
1 comment
[ 2.8 ms ] story [ 15.3 ms ] threadIn my experience (and in disagreement with the author) tech debt is inevitable - it's not the consequence of "suboptimal code" and "taking shortcuts" but rather the consequence of business requirements evolving beyond the system's architecture.
There's a delicate balance in the right amount of "technical leverage." It's very easy to grind to a halt over-engineering a system for all possible future requirements (some of which may never be needed!). On the other hand, it's easy to architect a system too shortsightedly such that any modification is difficult to do.
The best approach I've seen from technical leaders is to use new feature sets/initiatives that come from the business as an opportunity to clear up technical debt in the process. That way, you can guarantee that the architectural direction you're taking is aligned with business needs and that you're not wasting time on unnecessary improvements.