[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