The best working definition of technical debt I know is “Work you purposefully put off now, knowing that doing so will create more work in the future“. That’s a bad thing, right? Well, not always. Creating technical debt can be like borrowing money; you know you will have to pay it back with interest in the future, but what you can do with the money today can be more valuable than the future cost. Similarly, getting that feature out the door in this release, knowing you have edge cases it won’t handle or a clunky implementation that will come back and bite you if not refactored soon, can be well worth it. It means being more agile, capturing market share sooner, and getting feedback from the customer sooner. Creating technical debt is sometimes necessary because “Perfection is the enemy of good” (or done).
Just like that loan, you have to pay it back, and generally speaking, the longer you wait the harder and more expensive it is to do so. This can be hard to do, because
- You have to remember it to fix it
- Just like defects. the longer they exist the harder it is to get back in that context and remember all the details
- That technical debt is competing for resources with shiny new work that people want to work on, and others want done
In Agile, we are often told that everything we do should add value to the user. When you’re building something large and complex like an eCommerce or FinTech product, some work just isn’t user-facing, and it feels very forced and unhelpful to word the story in the “As a user I want to ___ so that ___” format.
We’re also told that stories should be as small as possible. But sometimes it takes several stories to get things working end to end to the point that users will gain some benefit from it, even if it is customer-facing. It’s also easier to do this in a published, working system you’re mostly adding small features to, but harder when you’re working towards your MVP, or early releases after that.
One solution to these seeming contradictions is to widen your definition of “user” to include the development community. Now, stories that make the system more testable, more flexible, more inspectable, more reusable, are all providing user to the user in a meaningful way. Adding functionality to lower systems, taking care of technical debt, adding logging, are all adding value to the user.
Back in 2016, I attended the Agile Alliance Technical Conference (since renamed Deliver:Agile, which I think was a HUGE mistake, but that’s for another article) I saw a keynote by Uncle Bob Martin called The Future Of Programming (video of that keynote here). It was powerful, insightful, and not ashamed to point fingers. The other day, I found a video on Youtube of a similar talk by Uncle Bob here, and I felt compelled to spread the word about his message, even more relevant in 2019.
The overarching theme of the talk was the history of computers, from the “beginning” to the present, but also who was designing them and programming them, how that was done, and how all of those changed over time, for better or worse. He also does an interesting approximation of the number of computers and number of developers through the years.
This article is about The Dev group in relation to other business units in the company. In this article, “the Dev group” is shorthand for whatever business unit the software development team is in (Technology, IT, …).
Many times in a company, the Dev group is seen not as a consumer of requirements and a provider of solutions, but as somehow subservient to other groups, like Marketing. The Dev group has to be very careful not to challenge their statements in meetings, and just accept that they know what they’re doing, no matter how little it’s based on actual customer feedback, or how SWAG the finance estimates are, or how much of their input is colored by personal bias. I’ve been taken off of meeting invites because I dared to challenge the statements about the Dev group and defending them from other business units. We even say things like “Let’s find out what The Business thinks of these features” as a short hand for “the other business units”. But phrasing it that way implies that the Dev group isn’t a separate but equal business unit.
I think a lot about process, process improvement, productivity, and efficiency vs effectiveness (believe it or not the difference is not universally understood). Lately I’ve been thinking a lot about team composition and how it affects the productivity of the team. In part I’ve been thinking about it because of the teams I’ve had in the past; in part because I’m currently hiring and having to make trade-offs like salary level vs skill level and overlapping skill sets, but also because I’ve been playing the game Overwatch a lot, where team composition essential.
MVP stands for (in this article) Minimum Viable Product. It’s not an Agile concept. It’s not even a software-specific concept, though it’s certainly easier to do with software, since upgrading software is usually easier than upgrading hardware. The concept is simple: Instead of building every feature under the sun into your product then releasing it, build the least you think people will buy and release that, following up with more feature-rich versions. There are several good reasons to do this.Continue reading