3 ms·

My experience is that it's often not the developers at all that cause a program to get bloated, but constantly changing client/user expectations. Or in other w

by CM30 11y ago

My experience is that it's often not the developers at all that cause a program to get bloated, but constantly changing client/user expectations. Or in other words, a program is developed and it starts out simple. Then, one of the following happens: 1. The user/client comes across edge cases, and has a very specific thing they want done in that situation. Unfortunately, it's the complete opposite of what the system would usually do, so said case has to be specifically patched to act in a certain way despite making the codebase a confusing mess to figure out. So one tiny part of a certain web page gets different padding or line height because the client/user thought it looked better in that one situation, and no one thought to say it was a bad idea. 2. The project's spec was wrong and hence it was the wrong thing to be building in the first place, but no one liked the idea of starting from scratch. So you end up with a program that's meant to do one thing but has been crudely hacked into doing something completely different and hence half the features are utterly useless. So it's not the developers fault in these cases, its management not knowing what the team is actually meant to be building or spending a lot of time trying to provide exceedingly random and useless 'nice to have' touches.

nradov 11y ago
You can't blame that on the "management" boogey man. It's unreasonable to expect managers to predict future customer requirements. If they guess right it's probably due to luck and not repeatable. Agile best practices of having product owners in close touch with customers, and getting frequent customer feedback through continuous delivery, can mitigate this problem but not prevent it. Software evolves and grows over time; that's the nature of the beast. In some cases it can make sense to go back and remove functionality that's no longer needed but that's tough to justify when you have limited engineering capacity and customers are offering to pay you actual money for specific new features.
jrcii 11y ago
> random and useless 'nice to have' touches We can probably conflate this type of problem with the second you mentioned. If the changes are that much of a problem there is probably something wrong with the software architecture. From a programmer's perspective it's easy to forget that the code exists to serve the user's experience, the user's experience shouldn't be crafted to serve the code.
drawkbox 11y ago
Completely agree with this assessment. The way software is completed is pretty crazy today, little time for research and development and a lack of focus on quality, but focused on short term changes that cost long term technical debt. Estimation is hard and project plans are only ever about 60-70% right. There is a big problem with not allowing sliding dates as well. When software is completed one day early that is a pile of crap it is lauded short term and painful longer term submerged in technical debt, then when more time is taken up front for quality it is short term pain for long term gain later on the maintenance phase. The problem is the latter is hard to do with development schedules not set by developers. Note: I accidentally hit downvote as my mouse glitched and wish I could reset that.
- collyw 11y ago
  Agile
Spellman 11y ago
And it's not even necessarily due to a bad spec. I work on a very large and evolving code base. And part of the R&D process is to throw difference features at the product to see if it improves the health. But at the same time we can't break prior features. It isn't that we had a bad spec. It's that the spec changes as we discover new methods and try out different ideas to continue towards incremental improvement. I personally have had to forcibly break a script and tell other developers to stop using a particular function because it was archaic and wasn't used in production for several months. And yet, somehow, a month later people would come to me complaining I broke their scripts since it was relying on an old feature we had long depreciated in favor of a much better version.
aryehof 11y ago
While changing requirements/expectations are part of the problem, I find that projects based on increasingly complex technical stacks and frameworks that impede functional changes are another. Those bloated technical parts tend to be focused solely on supporting (and providing flexibility for) non-functional requirements. Is it then a surprise that functional changes can't be handled effectively? Perhaps that is because developers really focus on technologies, not how to represent a complex business problem or systems into a model which is represented in code. Representing the business problem in a system, including changing functional requirements seems to be both a lost art, and a forgotten need.

by CM30 11y ago

nradov 11y ago

You can't blame that on the "management" boogey man. It's unreasonable to expect managers to predict future customer requirements. If they guess right it's probably due to luck and not repeatable. Agile best practices of having product owners in close touch with customers, and getting frequent customer feedback through continuous delivery, can mitigate this problem but not prevent it. Software evolves and grows over time; that's the nature of the beast. In some cases it can make sense to go back and remove functionality that's no longer needed but that's tough to justify when you have limited engineering capacity and customers are offering to pay you actual money for specific new features.

jrcii 11y ago

> random and useless 'nice to have' touches We can probably conflate this type of problem with the second you mentioned. If the changes are that much of a problem there is probably something wrong with the software architecture. From a programmer's perspective it's easy to forget that the code exists to serve the user's experience, the user's experience shouldn't be crafted to serve the code.

drawkbox 11y ago

Completely agree with this assessment. The way software is completed is pretty crazy today, little time for research and development and a lack of focus on quality, but focused on short term changes that cost long term technical debt. Estimation is hard and project plans are only ever about 60-70% right. There is a big problem with not allowing sliding dates as well. When software is completed one day early that is a pile of crap it is lauded short term and painful longer term submerged in technical debt, then when more time is taken up front for quality it is short term pain for long term gain later on the maintenance phase. The problem is the latter is hard to do with development schedules not set by developers. Note: I accidentally hit downvote as my mouse glitched and wish I could reset that.

collyw 11y ago
Agile

Spellman 11y ago

And it's not even necessarily due to a bad spec. I work on a very large and evolving code base. And part of the R&D process is to throw difference features at the product to see if it improves the health. But at the same time we can't break prior features. It isn't that we had a bad spec. It's that the spec changes as we discover new methods and try out different ideas to continue towards incremental improvement. I personally have had to forcibly break a script and tell other developers to stop using a particular function because it was archaic and wasn't used in production for several months. And yet, somehow, a month later people would come to me complaining I broke their scripts since it was relying on an old feature we had long depreciated in favor of a much better version.

aryehof 11y ago

While changing requirements/expectations are part of the problem, I find that projects based on increasingly complex technical stacks and frameworks that impede functional changes are another. Those bloated technical parts tend to be focused solely on supporting (and providing flexibility for) non-functional requirements. Is it then a surprise that functional changes can't be handled effectively? Perhaps that is because developers really focus on technologies, not how to represent a complex business problem or systems into a model which is represented in code. Representing the business problem in a system, including changing functional requirements seems to be both a lost art, and a forgotten need.