What types of features consistently lead to technical debt in your world? Like, a manager or client asks for this and you just know it won't end well.
For further actions, you may consider blocking this person and/or reporting abuse
What types of features consistently lead to technical debt in your world? Like, a manager or client asks for this and you just know it won't end well.
For further actions, you may consider blocking this person and/or reporting abuse
Latest comments (41)
I've worked at a lot of places with a lot of tech debt and after some close analysis I think I can definitely say that the feature most strongly correlated with tech debt is capitalism.
I noticed two popular types of problems:
Also, here I wrote an article how I prefer to do manage technical debt, maybe you can find something useful there.
dev.to/apastuhov/how-to-manage-tec...
I seem to get into trouble almost every time I start using some new language/framework/concept/etc I haven't used before ... in a tight-scheduled project :)
I know I shouldn't, but I can't help myself ... want to learn new things all the time. And so I spend the nights trying to get back on track :P
But about features ... I think that features changing physical processes (or how people use the software) tend to have too many iterations because people discover (too late) that they "forgot" to mention how they "really" want to use the system and that what they meant (when they described the problems) was actually something different than what I understood :)
Any time someone wants to get an ad hoc notification as a result of some action. Whether this is a user getting a push notification for an isolated action, or the dev team getting an email under certain conditions. There are definitely ways to build out a robust notification and reporting solution, but often times I see a request to tack on a notification to a piece of functionality, and it can lead to noise and frustration. Paying down the debt of cleaning up noisy notifications, or debugging notifications that aren't firing properly, can be incredibly painful.
Yeah definitely. I think you can get ahead of this with a really good observer pattern setup and general observability excellence, but building that is burdensome on its own. Fat chance implementing the perfect architecture to handle arbitrary last-minute notification needs unless it's already a true core competency.
“consciously decided on some tradeoff” - This is deliberate technical debt according to Martin Fowler’s Technial Debt Quadrant
Any feature that has to be delivered faster than it should be delivered.
When developers last question to stakeholder is "Are you absolutely sure this is what you want me to do?"
1) Any time you add "todo" notes
2) any time you don't add unit tests with new features
3) any time you don't add documentation with new features
4) any time you don't test for edge case input
For #4, I'm currently working on a document, at least for PHP (but can apply to others), that shows a ton of different data types and values that can be passed into a function which are generally overlooked or the developer simply doesn't know about them. Is great to unit test edge cases like these to help prevent bugs. I'll have more on this when the document is live!
A transaction is an atomic sequence of executed features. (This as a whole would also be a feature.)
To use a bad car analogy. A SUV would be a feature that tries to do two things. And neither of them it does great. Trying to change either feature would also impact the other feature. While it all may work the effort for change/maintenance is higher. There is of course the hope that if work needs to be done on both features the total amount of work is less than when work on those features would need to be done independently.
Normally its things that involve big data, that is coming from a 3rd party.
When you have no control over how the data comes and just have to work with what you're given...that tends to cause problems