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
Luxand.cloud -
Akpevwe11 -
Jima Victor -
Mark Smith -
Top comments (42)
Features that are completely unlike anything you've implemented before, because a lot of infrastructure needs to get set up to support that one feature, and you may not have time to plan it all out properly.
Alternatively, features that are nearly the same as an existing feature, but have a few significant differences. Either leads to lots of duplicated code, or else a bunch of hacks in the current code to make it also work for this edge case.
One-off feature requests which are of the form "We need this for today, nothing fancy, just a special check for X customer". The problems with these are:
IMHO, the best way to answer these kinds of requests (depending on how mature your company is) would be flat say no or ask for enough time to implement it in a sensible way.
A caveat for startups. Many startups are still experimenting with their core product when they launch. Such features are needed for fast iteration and feedback. Being ruthless in removing code for failed experiments is required to manage code base.
+1 to "Poor Planning" here. Technical debt is, as other users have mentioned, meant to be a conscious decision. Engineers need to make constant trade offs when developing software and technical solutions. Without proper planning, it's likely that engineers don't have all the information they need to make educated decisions about trade offs, leading to poorly implemented or short sighted solutions. If you're unable to consciously understand the trade offs you're making, you'll likely wind up with unintended technical debt or an inadequate solution.
I've never really considered it that way, but you're totally right in that tech debt is exactly that: debt. Having a credit card isn't a bad thing if you can pay it off in a timely manner, just like writing "bad code" or rushing a feature for a timeline isn't necessarily bad if you take time to pay down that debt after release. But if you have a pattern of consciously choosing to add features and never pay it back, then you start to get in trouble.
Tightly coupling features to particular things, such as customers, vendors, products, events or even hardware.
A real world example: A manufacturing company has made 12 different product lines for about 15 years. All software gets written around this fact. Suddenly, one day, there's a urgent need to expand it to more product lines because of a big contract with a certain big retailer. That's when things start to break all over the place because everything from the database to the front end is written specifically for 12 product lines. What the company did in this situation is to setup separate databases and apps for the new product line by making copies of the existing software. But there were other things tightly coupled so that didn't work. It almost sunk the company.
Similar thoughts here, once had to maintain a system that was stuck on SPARC hardware and Solaris 2.0 because of a binary blob we couldn't change. The least worst fix was to facade & isolate the blob on a separate system near the cause of it's existence. Still fugly..
Anything that contains
I can nearly guarantee a feature will be technical debt, when a user has asked for it to meet organizational requirements that have nothing to do with the application's normal usage. When I implement it, I always know it is going to be a thorn in my side. Executives and managers are always coming up with new initiatives and policies. So then the code has to be reworked for non-functional reasons. Or it might just become unused cruft which is supplanted by another new org-overhead feature. And with every core-feature change I make, I must consider the impact to the org-overhead features even though it has no importance to the core use cases.
Users tend to not be able to differentiate between what features they need to accomplish their work and what things are just organizational cruft. So they always ask for (or outright demand) features like this. Nowadays, I try to determine what use case is driving a feature request. If it is not the main purpose of the app, I look for alternative ways to help the user meet those organizational requirements without generating tech debt for me. For example "What if I give you a CSV of the data so you can play with it in Excel?" Or "How about using X product to accomplish that?" Or "Does this really need to integrate with BizTalk?"
Answers like these help the user solve their problem and also avoid writing code that will be a grief to me in the future.
The magical words you hear too often in consulting are "the customer asked for this".
They make you wonder if PMs are doing their job or just saying yes to whatever the customer asks them for :D After a few "yeses" veering off the core product you tend to accumulate a lot of debt already.
Maybe PMs should be UX designers or UX designers should be the ones talking to the customers and let PMs run the day to day of the project.
A couple things that come to mind for me:
Also "prototypes" that become the final version :D
As a super beginner dev, I'd like to know a little bit more about why A/B testing might qualify as a practice that leads to tech debt.
It seems like something that giants like Google and FB do all the time. Is A/B testing not a practice intended to prevent tech debt?
A/B testing is, in my experience, usually an attempt to improve some business metric like landing page conversions and engagement etc. They're great if done right, but they inherently add a lot of complexity and coordination that can cause holes that are hard to dig out of.
Big orgs do a lot of A/B testing, but they devote the resources to making it work, and I'm sure they still have their issues. Smaller engineering orgs get in trouble trying to add split testing into an already rigorous workload.
There is also a stats issue involved. And how many misunderstand stats.
Seen way too many startup spending way too much time trying to use A/B, as a means to try find a magical 10x conversion rate improvement through it. With sample size of under a thousand.
Over simplifying, my rule of thumb, until one reach over a million hits per month, or a team of 50, one should never consider A/B. Till then incremental improvement and feedback is good enough.
Technical debt isn't just about bad code. It is about the price you have to pay for going back to that code to make changes.
Bad code, and even bad architecture can have zero technical debt when it works, and does not require change.
I don't think you have to consciously decide to take on debt in code. First of all, you could just not realize you're making a bad decision. Maybe you are inexperienced. Second, and I think more importantly, you can do everything right based on the information you have at that moment and then it becomes debt later as you get more information, understand more about new use-cases, etc. This is an oldie but a goodie by Martin Fowler - martinfowler.com/bliki/TechnicalDe...
I don’t know if this helps, but I think there are three factors that can all contribute to technical debt:
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.
"Let's focus on stability later."
This is an excellent point. I'm going to start advocating for this interpretation.
I think I generally use the term as you described, choosing what feels like a hack or shortcut over a properly engineered solution because of the time costs.
Relevant book recommendation: Clean Code, by Robert Martin.
The security later philosophy. Badly implemented auth, relying on exact input for stable execution, no systematic testing, all such things will be hard and costly to implement at a later time.
This isn't exactly features, rather it's about whatever features get precedence.