cdzombak + technicaldebt   12

A Taxonomy of Tech Debt | Riot Games Engineering
When measuring a piece of tech debt, you can use impact (to customers and to developers), fix cost (time and risk), and contagion. I believe most developers regularly consider impact and fix cost, while I’ve rarely encountered discussions of contagion. Contagion can be a developer’s worst enemy as a problem burrows in and becomes harder and harder to dislodge. It is possible, however, to turn contagion into a weapon by making your fix more contagious than the problem.

Working on League, most of the tech debt I’ve seen falls into one of the 4 categories I’ve presented here. Local debt, like a black box of gross. MacGyver debt, where 2 or more systems are duct-taped together with conversion functions. Foundational debt, when the entire structure is built on some unfortunate assumptions. Data debt, when enormous quantities of data are piled on some other type of debt, making it risky and time-consuming to fix.
technicaldebt  programming 
6 days ago by cdzombak
Paying Down Technical Knowledge Debt
Technical knowledge debt is like technical debt

If I accrue too much debt, my work slows to a crawl. I have to spend a significant amount of time paying it off.

On the other hand, if I pay it off as I go, individual tasks take longer, but I never come to a complete stop.
programming  learning  technicaldebt  knowledge 
october 2016 by cdzombak
Towards an understanding of technical debt - Laughing Meme
Suggesting that common usage of the term "technical debt" conflates several different problems. Having more precise terminology to use in these discussions is helpful.
There are at least 5 distinct things we mean we say “technical debt”.

1. Maintenance work
2. Features of the codebase that resist change
3. Operability choices that resist change
4. Code choices that suck the will to live
5. Dependencies that resist upgrading
technicaldebt  programming  complexity  falsedichotomy 
january 2016 by cdzombak - The soccer ball and the solar system
on changing a system's architecture over time.
In the solar system model, rather than trying to define a complete set of components and set teams off to decouple things in accordance to your grand new architecture, small teams gradually carve out pieces of your monolith when the churn on those pieces is significant, and engineer them using a new set of tools optimized for much smaller codebases.

What you end up with is a "star" monolith, which shrinks slowly over time as engineers spin off new "planets": their own microservices that "orbit" the star, providing it with essential services. You might add more planets as organizational changes or small pieces of new functionality come online, until you end up in a transitional state where you still have a significant chunk of your code living in the star, but 40-50% of your developers' day-to-day jobs are dealing with planets and their faster, lighter-weight processes.
technicaldebt  software_architecture  management 
july 2015 by cdzombak
Good Tech Lead, Bad Tech Lead — Medium
A brief guide to tech leadership at Foursquare, inspired by Ben Horowitz’s Good Product Manager, Bad Product Manager.
programming  leadership  management  teamwork  engineering  technicaldebt  communication  product_management 
january 2015 by cdzombak
Why non-engineers should care about “Technical Debt” # Chris Dzombak
Taking technical debt is reasonable at times, but if you don’t prioritize paying it back (listen to your engineers!) your customers will start to notice and suffer. And fixing that is going to be a whole lot harder later than it is now.
technicaldebt  ux  product_management  product  engineering  falsedichotomy  via:cdzombak 
january 2015 by cdzombak
Bad code isn’t Technical Debt, it’s an unhedged Call Option – Steve Freeman
So, the next time you have to deal with implausible delivery dates, don’t talk about Technical Debt. Debt is predictable and can be managed, it’s just another tool. Try talking about an Unhedged Call. Now all we need is a way to price Code Smells.
technicaldebt  programming 
january 2015 by cdzombak
Technical debt 101 — Medium
An in-depth discussion of technical debt.

• analogies that work, or don't
• what it is, vs. just bad code
• the choice to take on technical debt; when it may or may not be justified
• how to handle technical debt once you've taken it
technicaldebt  bestpractices  management  programming  falsedichotomy 
august 2014 by cdzombak
The one cost engineers and product managers don't consider
A well-written argument that puts complexity and development time into context of an entire product's lifespan, and the responsibility of every team member to mercilessly fight for simplicity.

Several choice quotes:
The work of implementing a feature initially is often a tiny fraction of the work to support that feature over the lifetime of a product. In fact, I'd argue that the initial time spent implementing a feature is one of the least interesting data points to consider when weighing the cost and benefit of a feature.
Everyone owns velocity, and the least important factor in your engineering team's velocity is how hard everyone is working. Developers need to openly discuss the complexity costs they're paying right now, those they're worried they're taking on with proposed specs, and to propose alternative product designs that can save complexity.
Your product management, QA and development teams should be using judgment to decide what should continue to exist and not just blindly adding everything that used to exist.
Software developers like challenges, and the challenge of building a complex system that serves up a simple interface is especially alluring.
Writing the lines of code is rarely the big cost in engineering: it's the understanding, the communication and the maintenance.
complexity  simplicity  technicaldebt  product  via:andrewsardone  engineering  management 
july 2013 by cdzombak

Copy this bookmark: