The larger a project is or the busier developers are, the harder it is to become acclimated to parts of the code, too.
There are a few more examples from the article:
Bugs pile up. The build slows. Backwards compatibility imposes its own tax on progress. Original team members move on, while new members take time to acclimate.
He doesn’t mention this, but it also takes time to re-acclimate yourself to things you wrote six months ago. Good code and tests help but developers are human beings.
Technical debt aside of course the development process looks like that - what's the alternative? Infinite feature growth? No one benefits from that.
As an example, I've got signal on my phone- it started with texting features, added images, calls, video calling, but at some point there's a limit on the number of useful ways to communicate.
I don't need it to be another social network.
I don't need it to tell me my horoscope, order a pizza, or organize my photos.
I don't need it to track my health, play games, read my work emails, or drive my car.
It doesn't need to integrate with VR, or AI, or whatever 2-letter buzz acronym comes up next week.
It's a secure messaging platform, I need it to send messages. Sure, there's always a cat and mouse game of encryption to keep ahead of, but infinite feature growth? It's not practical or necessary. Things can exist to do one thing reliably and well.
Which is basically doing the easy stuff first. There's no tech debt and you can get a MVP up and running quite quickly with the intent of refactoring later, which almost never happens and then when you are filling in the details, you have the tech debt from the MVP slowing you down.
It's a lot harder to get a new feature to interact properly with 30 existing features. If you have to change one thing about an existing feature to get it to work, you now have to look at how the other 29 deal with that change too. And any changes to accommodate that change also could require their own changes in those 29... And it cascades.
@NABDad
"Low Hanging Fruit" just means "easy wins"...
I hasten to add that no fruits are "low hanging" until "what the thing is actually for" works. If your product doesn't "do the thing", it doesn't make a lick of difference how nice the content management module is or how smooth the social media login workflow is or how retina resolution the logo is ...
More code = more things that must be maintained = more things that can break. It’s natural that development slows down over time. Doesn’t necessarily mean there’s technical debt.
13 Comments
falseWhite@lemmy.world · 44 pts · 282d
calliope@retrolemmy.com · 19 pts · 282d
Refactoring is great, but there’s more.
The larger a project is or the busier developers are, the harder it is to become acclimated to parts of the code, too.
There are a few more examples from the article:
He doesn’t mention this, but it also takes time to re-acclimate yourself to things you wrote six months ago. Good code and tests help but developers are human beings.
Ludicrous0251@piefed.zip · 16 pts · 282d
Technical debt aside of course the development process looks like that - what's the alternative? Infinite feature growth? No one benefits from that.
As an example, I've got signal on my phone- it started with texting features, added images, calls, video calling, but at some point there's a limit on the number of useful ways to communicate.
I don't need it to be another social network.
I don't need it to tell me my horoscope, order a pizza, or organize my photos.
I don't need it to track my health, play games, read my work emails, or drive my car.
It doesn't need to integrate with VR, or AI, or whatever 2-letter buzz acronym comes up next week.
It's a secure messaging platform, I need it to send messages. Sure, there's always a cat and mouse game of encryption to keep ahead of, but infinite feature growth? It's not practical or necessary. Things can exist to do one thing reliably and well.
Vincent@feddit.nl · 4 pts · 282d
I'm very happy they've got polls now though, that'll streamline a lot of communication. Live location sharing would be good too.
NABDad@lemmy.world · 9 pts · 282d
Maybe I'm not looking deep enough into the question, but wouldn't this be because we do the easy parts first?
falseWhite@lemmy.world · 9 pts · 282d
MyNameIsRichard@lemmy.ml · 3 pts · 282d
Which is basically doing the easy stuff first. There's no tech debt and you can get a MVP up and running quite quickly with the intent of refactoring later, which almost never happens and then when you are filling in the details, you have the tech debt from the MVP slowing you down.
Bronzebeard@lemmy.zip · 3 pts · 282d
It's easy to connect two features together.
It's a lot harder to get a new feature to interact properly with 30 existing features. If you have to change one thing about an existing feature to get it to work, you now have to look at how the other 29 deal with that change too. And any changes to accommodate that change also could require their own changes in those 29... And it cascades.
MyNameIsRichard@lemmy.ml · 2 pts · 282d
That would be my guess also.
EndlessMason@hachyderm.io · 3 pts · 282d
@MyNameIsRichard @NABDad
There's nothing in the way at the start, no other stuff to avoid breaking, nobody depending on a thing you can't move.
They're easy because you did them first
NABDad@lemmy.world · 1 pts · 282d
That's certainly true, but I think there's also a lot of "low-hanging fruit" that gets knocked off the list early.
EndlessMason@hachyderm.io · 2 pts · 282d
@NABDad
"Low Hanging Fruit" just means "easy wins"...
I hasten to add that no fruits are "low hanging" until "what the thing is actually for" works. If your product doesn't "do the thing", it doesn't make a lick of difference how nice the content management module is or how smooth the social media login workflow is or how retina resolution the logo is ...
magic_lobster_party@fedia.io · 5 pts · 282d
More code = more things that must be maintained = more things that can break. It’s natural that development slows down over time. Doesn’t necessarily mean there’s technical debt.
bestboyfriendintheworld@sh.itjust.works · 4 pts · 281d
Complexity is inherent an unavoidable.
MonkderVierte@lemmy.zip · 3 pts · 282d
Because each feature is a cost.