4 ms·

Call me a starry-eyed idealist, but > The iterative bloat during development can happen for so many reasons. (Numerous changes in requirements late in the proj

by alch- 11y ago

Call me a starry-eyed idealist, but > The iterative bloat during development can happen for so many reasons. (Numerous changes in requirements late in the project, ... and people not cleaning their mess up afterwards; > many developers working on numerous modules, ... without proper coordination, or, without the drive to keep things clean (i.e. proper manners); > design for flexibility and expansion that are never used, ... and never cleaned up, i.e. left there to rot by the people who put them there; > going too far down a path that turns out to be more work than an alternative) ... and not cleaning up. > Once a program has been in production for a while and its use cases are more well defined it becomes easier for a single person to swoop in and rewrite it in a far more conscice way. I think it's always easier for the guy/gal who wrote something to clean it up than for the next guy/gal, who doesn't know the code or its history as well. Really, this is all just people not cleaning up (or being allowed to clean up) after themselves. Now if we could all just be nice to each other and hold hands..

gnarbarian 11y ago
Coming from a 10 year veteren in consulting for orgs ranging in size from 3 people to federal departments. Most of the time there isn't any budget left after they have a functional app for cleaning things up. Despite impassioned hand wringing the client will place value on things they can see over things they can't. So any budget left over will almost invariably be directed toward additional features and not on proper engineering. Sad but true. Speaking to your points there's also the problem of not being able to see the forest through the trees for developers who have been with a project from the beginning. So large refactoring endeavors can be less obvious to them. They may also have fatigue and be less willing to rewrite everything. This combined with budget pressure is all it takes for the bloat to stick.
- marcus_holmes 11y ago
  The point and purpose of commercial programming is profit, not beautiful code. Yes, I know, tech debt is a thing and those that don't pay attention to the engineers will soon find themselves with a shitty code base that they can't sell. It can be really, really hard to persuade a management board that you need to take a bunch of their expensive techs to not write new features that will improve saleability, but instead rewrite the code-base (that they're still depreciating), for no net gain (and considerable risk) except to maybe reduce the support overhead and make future developments easier and cheaper.
- Joeri 11y ago
  After my own decade of enterprise programming i can there only two ways to obtain clean code. Either you build it right from the start, or you make a cleanup a blocking requirement before a high value feature can be added (which often requires a liberal interpretation of the word 'blocking'). I'm a fan of the first approach. Building it right is the most efficient way to build, with the overall lowest amount of effort required. It doesn't mean gold-plating, rather the opposite: keeping things light, elegant and minimal. Anything that can't be built cleanly isn't built at all (yet), or at the very worst it is mocked with a fixed data implementation, which suffices for demos but not for shipping. However, the problem with building it right is that you have to learn all the wrong ways to build before you learn how to stick to the narrow path of clean code. I wish we could do brain dumps from old hands to young wolves and not see the same mistakes repeated by every generation of programmers.
  - gnarbarian 11y ago
    Here's a anecdote of how a typical webapp goes to shit with the best intentions from everyone. "building it right from the start" sounds great. I've never worked on a project where people did not honestly try to do it this way. Lets say that for once you have a clear set of unambiguous requirements (a rarity) when starting in. I like to start with the database first. I'll design a nice normalized database and start building the website from there. If the requirements are fleshed out enough you'll already have a map of what pages ought to do what. Once you get to the point where you can have a customer try out a few pages you get some "feedback" which is actually a change in the requirements. You can't hit them with a change request for every little thing at first so you comply. Maybe it's just a small change turning a one to many into a many to many relation for example, or moving a few fields from one table to another. Soon you have 30 or so similar "small tweaks" even if you hit them with a change request every time, they don't all come in at once giving you a good opportunity to re-evaluate the schema/application as a whole, it's always viewed as a singular "small" change so re-factoring the whole thing isn't really an option. The more changes that come through the more your elegant implementation becomes a series of hacks. Soon they may start complaining asking why their "small" changes are taking so long to fix. This adds further budget pressure. The problem is, it's not very clear to people down in the weeds when implementing the small changes if it's a hack or not. I think this is something that takes experience. So even when you have cleanup be a blocking requirement, taken one at a time it might seem fine and no large refactor is obvious until it becomes too large of a task to lump in a typical change request. This is an especially easy trap to fall into for people who have been toiling away at the current design. They will have a blind spot/affinity for keeping as much of their implementation as possible and resist an overhaul. If you have an iron will and a steely ice cold 1000 yard stare from 10 years of war in enterprise app development it's easier for us to kill code because we don't get attached to it as easily. Be careful not to fall into the dark side though, (the flip side of those 10 years can instil a cold iron heart who stares right through the hacks and stops trying to argue with the client about doing things properly. In this scenario you just do as you are told and stop caring about the overall state of well-being of the codebase.) The real art to web dev consulting is being able to build a flexible enough design to withstand these sorts of changes and still remain elegant and well thought out. It also takes the experience to know the difference between a hack and a proper change and the will power to do the right thing. It's really hard to do and it a good "gut" feeling for how a particular thing will actually be used, what a customer really means when they say something etc. I'm not sure that it's something that can be taught. It leads right back to your brain dump wish. Cheers
foobarian 11y ago
>> Once a program has been in production for a while and its use cases are more well defined it becomes easier for a single person to swoop in and rewrite it in a far more conscice way. >I think it's always easier for the guy/gal who wrote something to clean it up than for the next guy/gal, who doesn't know the code or its history as well. Once a piece of functionality gets established in production, over time the knowledge of the original requirements and the implementation is lost. The consequence is that nobody knows why the code does what it does (and usually it does something important) and due to it working fine in production there is strong pushback to making changes.
- gnarbarian 11y ago
  That assumes the original requirements were correct. This is often not the case.
nchelluri 11y ago
If there is one thing I really hate it's deploying new code that has cruft/legacy shit already baked in. It just makes me feel awful. But sometimes, after so many months (or years, in at least one of my cases) on a project, I just say fuck it, and ship it (be it my code or a team member's). I definitely agree with your ethos though. I think there's a lot to be said for having some buffer between functionally complete code and a hard ship date so that you can leave things in a state that don't make you or someone else feel bad about things later.

by alch- 11y ago

gnarbarian 11y ago

Coming from a 10 year veteren in consulting for orgs ranging in size from 3 people to federal departments. Most of the time there isn't any budget left after they have a functional app for cleaning things up. Despite impassioned hand wringing the client will place value on things they can see over things they can't. So any budget left over will almost invariably be directed toward additional features and not on proper engineering. Sad but true. Speaking to your points there's also the problem of not being able to see the forest through the trees for developers who have been with a project from the beginning. So large refactoring endeavors can be less obvious to them. They may also have fatigue and be less willing to rewrite everything. This combined with budget pressure is all it takes for the bloat to stick.

marcus_holmes 11y ago
The point and purpose of commercial programming is profit, not beautiful code. Yes, I know, tech debt is a thing and those that don't pay attention to the engineers will soon find themselves with a shitty code base that they can't sell. It can be really, really hard to persuade a management board that you need to take a bunch of their expensive techs to not write new features that will improve saleability, but instead rewrite the code-base (that they're still depreciating), for no net gain (and considerable risk) except to maybe reduce the support overhead and make future developments easier and cheaper.
Joeri 11y ago
After my own decade of enterprise programming i can there only two ways to obtain clean code. Either you build it right from the start, or you make a cleanup a blocking requirement before a high value feature can be added (which often requires a liberal interpretation of the word 'blocking'). I'm a fan of the first approach. Building it right is the most efficient way to build, with the overall lowest amount of effort required. It doesn't mean gold-plating, rather the opposite: keeping things light, elegant and minimal. Anything that can't be built cleanly isn't built at all (yet), or at the very worst it is mocked with a fixed data implementation, which suffices for demos but not for shipping. However, the problem with building it right is that you have to learn all the wrong ways to build before you learn how to stick to the narrow path of clean code. I wish we could do brain dumps from old hands to young wolves and not see the same mistakes repeated by every generation of programmers.
- gnarbarian 11y ago
  Here's a anecdote of how a typical webapp goes to shit with the best intentions from everyone. "building it right from the start" sounds great. I've never worked on a project where people did not honestly try to do it this way. Lets say that for once you have a clear set of unambiguous requirements (a rarity) when starting in. I like to start with the database first. I'll design a nice normalized database and start building the website from there. If the requirements are fleshed out enough you'll already have a map of what pages ought to do what. Once you get to the point where you can have a customer try out a few pages you get some "feedback" which is actually a change in the requirements. You can't hit them with a change request for every little thing at first so you comply. Maybe it's just a small change turning a one to many into a many to many relation for example, or moving a few fields from one table to another. Soon you have 30 or so similar "small tweaks" even if you hit them with a change request every time, they don't all come in at once giving you a good opportunity to re-evaluate the schema/application as a whole, it's always viewed as a singular "small" change so re-factoring the whole thing isn't really an option. The more changes that come through the more your elegant implementation becomes a series of hacks. Soon they may start complaining asking why their "small" changes are taking so long to fix. This adds further budget pressure. The problem is, it's not very clear to people down in the weeds when implementing the small changes if it's a hack or not. I think this is something that takes experience. So even when you have cleanup be a blocking requirement, taken one at a time it might seem fine and no large refactor is obvious until it becomes too large of a task to lump in a typical change request. This is an especially easy trap to fall into for people who have been toiling away at the current design. They will have a blind spot/affinity for keeping as much of their implementation as possible and resist an overhaul. If you have an iron will and a steely ice cold 1000 yard stare from 10 years of war in enterprise app development it's easier for us to kill code because we don't get attached to it as easily. Be careful not to fall into the dark side though, (the flip side of those 10 years can instil a cold iron heart who stares right through the hacks and stops trying to argue with the client about doing things properly. In this scenario you just do as you are told and stop caring about the overall state of well-being of the codebase.) The real art to web dev consulting is being able to build a flexible enough design to withstand these sorts of changes and still remain elegant and well thought out. It also takes the experience to know the difference between a hack and a proper change and the will power to do the right thing. It's really hard to do and it a good "gut" feeling for how a particular thing will actually be used, what a customer really means when they say something etc. I'm not sure that it's something that can be taught. It leads right back to your brain dump wish. Cheers

foobarian 11y ago

>> Once a program has been in production for a while and its use cases are more well defined it becomes easier for a single person to swoop in and rewrite it in a far more conscice way. >I think it's always easier for the guy/gal who wrote something to clean it up than for the next guy/gal, who doesn't know the code or its history as well. Once a piece of functionality gets established in production, over time the knowledge of the original requirements and the implementation is lost. The consequence is that nobody knows why the code does what it does (and usually it does something important) and due to it working fine in production there is strong pushback to making changes.

gnarbarian 11y ago
That assumes the original requirements were correct. This is often not the case.

nchelluri 11y ago

If there is one thing I really hate it's deploying new code that has cruft/legacy shit already baked in. It just makes me feel awful. But sometimes, after so many months (or years, in at least one of my cases) on a project, I just say fuck it, and ship it (be it my code or a team member's). I definitely agree with your ethos though. I think there's a lot to be said for having some buffer between functionally complete code and a hard ship date so that you can leave things in a state that don't make you or someone else feel bad about things later.