Technical debt as a metaphor is not serving our profession well. It was meant to help us talk to business people and make better decisions about ou...
For further actions, you may consider blocking this person and/or reporting abuse
I could not have said it better myself. This is tremendous advice.
Thank you. High praise.
I've tried, with slightly inconsistent results, to encourage "non-technical" folks to contribute to learn how to make pull requests and do some basic coding. I think it helps foster some cross-domain empathy in the same sorts of ways you've outlined. It requires next-level buy-in and sometimes falls off, but it's been a good exercise at least.
But it's all a two-way street. Coders can't have contempt for others' perspectives. Mutual respect goes a long way.
Yeah, we haven't gotten to the "let's get the non-tech people coding" stage but we are working on basic empathy and teamwork. And that seems to be enormously helpful in getting more people rowing in the same direction.
As a developer with a fair amount of business-minded people in my inner circle, I couldn't agree more that empathy is key. I also agree with Ben's method of introducing "non-technical" people to the basic practices of a programmer, as it's able to demystify the work that is often written off as extraneous or too complex.
Consequently, creating a common ground for communication that is fundamental in developing an empathetic relationship.
Thank you for your comments, David. Let me see if I can clarify my thoughts.
What I'm trying to communicate in the first quote is that business people may not understand the consequences of pushing the devs to take a shortcut. They have their own priorities and objectives and if they can get the devs to deliver a new feature in x weeks, then that helps the business people meet their short term goals and they are happy. But if the devs sat the business people down and explained all the consequences of adding this shortcut to the other 2,000 shortcuts already in the system and how each added shortcut makes it that much harder to do anything in the future, and that their two best devs just quit over the low quality of the code base, they might be able to convince the business people to do something less distructive to the health of the software. Most devs don't push back against the business people or at least take the time to explain the damage certain proposed changes are likely to do to the software. When devs fail to advocate for their code, that's not very professional behavior in my books (and according to the Software Engineering Code of Ethics and Professional Practice).
In my second quote, I'm arguing that the devs can't afford to take a hard line either. There may, in fact, be very good reasons to damage the health of the software to achieve an important short term business goal. For example, it might be worth hacking in some new business rule if it meant keeping your biggest client and avoiding bankruptcy.
Both these quotes support the overall thesis of my post, which is that we need to have better cross-functional communication to make our maximum contribution to the success of the businesses for which we work.
I forgot to address one point. A dev adding a 300th method to a class at my work isn't creating technical debt, he's writing crappy software that's not going to pass code review.
So we are probably in slightly different work situations. You're battling crappy code so, yeah, you probably aren't aware of the effect of the business people when you've got stuff like that going on.
Thanks for the read. This was a great article! I think that bringing the business people closer to the development process is a good idea. I myself am a developer, yet I find that I'm regularly surprised and annoyed by how much more difficult something is to actually do compared with describing it conceptually. I imagine it must be even harder for non-technical people to do deal with the frustration of how long features take to implement.
Thanks for reading.
Yes, I think non-technical people are often very frustrated with developers. There might be very good reasons for it but we (software developers) are absolutely terrible about keeping our commitments.
I think there is a distinction between technical debt and crap code, but I don't find the need for debt to be "intentional". As I meantioned in my article on debt, you'll just accumulate debt over time even if you're not intending on doing it.
Any new requirement has the potential of rendering existing code sub-optimal. Often it's not until several such new requirements arrive can this realization be made.
"once you allow your project to turn into a mess, it's really difficult to clean it up (in many cases it might be impossible)" -- If this is true then I should be charging more for my services. :D
"If the business people truly understood the risks and costs of these shortcuts," -- This is part of the job description of a programmer: Making business understand the risks and costs, of course, that first we require understanding them ourself.
"trying to maintain and extend a software project full of crappy code is frustrating, soul-crushing work." Yes agree, and starting to wonder if specializing in soul-crushing work may be a lucrative field. :)
You are correct on several counts. Debt will accumulate over time even if no intentional debt is accepted and crappy code is not counted as debt.
I've thought about specializing in soul-crushing work but it probably wouldn't be that lucrative most of the time. You'd need to find a client who somehow:
The overlap in the venn diagram of those four factors might exclude the majority of projects.
With that said, I'd love to hear from someone who makes it work. I think Paul Jones (leanpub.com/mlaphp) makes some money doing consulting on this kind of thing but I don't know how much.
I agree. If a significant number of your teammates don't really give a crap, it's hard to make things better with improved communication.
Great article. I am actively cultuvating these conversations with management at my new employer. I’m going to keep this bookmarked.
Awesome. Thanks for reading and commenting.
Excellent write-up, thank you for sharing!
We read (and applaud!) all the same books. ;-)
Awesome. Thanks.
I'm so bookmarking this !
High Praise. Thank you.