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
dev.to staff -
dev.to staff -
Dev on Remote -
Alysa -
Oldest 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.
A couple things that come to mind for me:
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.
Also "prototypes" that become the final version :D
"Let's focus on stability later."
human input validation, time zones, "multi-cloud"
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.
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.
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.
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.
I'd say it something trivial which has a lot of "and's or also's" in definition and strict timeline, so if you hear something like:
"we want to have emailing functionality which will also send text messages and keep track of all the emails in salesforce in 3 days." <-- that would be a clear sign to me that at least a week of refactoring should be allocated to detangle it.
That would happen because pretty much any engineer knows how to do it and tight timeline pushes engineer to cut corners
everything which needs an ORM , of course.
Relevant book recommendation: Clean Code, by Robert Martin.
Features that try to do more than one thing.
Feature flags and Integration points to start.
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.
Social media integrations. Every time I've integrated some kind of 3rd party social media integration I end up having multiple bugs that I have to go back and deal with.