[wonderwonder]

Feature creep and timelines are in my opinion the root cause of lower quality software. Most engineers sit down planning to develop clean efficient code but that generally takes more time than they are allocated. As the deadline draws closer new features and edge cases are often added in by either management or the end user.

Often these new features were not accounted for in the original design and in order to fit them into the system in a nice and clean manner, a large rewrite of certain modules and/or database tables is required. Due to time constraints and developer fatigue this is not possible and the mindset of "Just get it done" sinks in. This is no one's fault just a harsh reality of writing software where timelines and profits are a factor.

No one wants to be the guy that hard coded several edge cases into an otherwise clean module but it happens and it happens often as "Just get it done" takes hold. I think a good developer just accepts this, and makes sure to do a good job commenting their code. This especially happens during customer acceptance testing. Customer brings up a feature that they never mentioned before, they want it now. Management and/or your bank account says just give it to them. You hard code it in.

The circle of life

[codeonfire]

I don't understand why people have a problem with hard-coding features. The argument is that it creates more work later. But this is a fallacy as the work "later" is not guaranteed to be necessary or requested. The idea that all software has to be abstracted, configurable, and future-proof to be "good" is just wrong. We hard code features all the time on my project. The earth keeps on spinning, the company makes money, and the code is usually removable with a single 'git revert' when the time comes to clean up. That time may never come, which is fine. That is the natural way. Nature has yet to do 'git revert male nipples' or 'git revert human appendix'. Both are dirty hacks left in by mother nature.

[Jtsummers]

Your comment reminds me of the time I spent reading Chuck Moore's writings and learning forth. One of the main things he endorses is keep it simple. Don't do things because you may need them. You don't need it now, so don't do it now. Factor your code later, or rewrite it if you have to. But there's little point implementing something that may not be useful in the future (or whose complexity costs aren't amortized over enough uses later).

I can abstract out some feature into a handful of classes, and then use that in one place in my code. Was it useful? Probably not. Now I use it in 20 places. Was it useful? Almost certainly. But if I don't have multiple places to use the abstraction, it probably isn't worth developing today.

[wonderwonder]

For me it has to do more with the idealized way to develop a project. You have a pretty plan & design, and want to see it executed. Unfortunately that rarely happens in real life. For example on my current project I wanted a very database driven design. Essentially just be able to update records in the database and everything on the site changes accordingly.

Last minute changes and exceptions to the rule made that impossible with the given deadline. You are absolutely correct in that the end result is completely fine and the world keeps spinning.

There are no real world consequences aside from needing to remember that there are hard coded exceptions in the code. Its just the hunt for the elusive "perfect execution and design."

[joshribakoff]

If your code is a mess of "this user has this feature on", "all users in this state have this other feature off", etc it's hard to revert. Especially when that mess is everywhere from years of changes. Reverting otherwise working features upsets customers. So now you have to write a rules engine to be able to replace all those hard coded use cases. Except that's not in the budget. Continuing to layer on workarounds also becomes more tricky. If you have to test as 1000 different users to hit all he edge cases, you're going to end up not testing, which results in more bugs which begets more hacks. It's a slippery slope