|
Well, first thing, in the Computer Science part of programming, the requirements are very simple and straightforward. For example, implementation of hashing algorithm or HashMap. You just can't compare the requirements of "science" part with requirements of "real world business system". The "science" requirements are almost laughably trivial. And the documentation of business system will run into thousands of pages. Now, you say if you just refactored the code, if you saw the "grand design" and rewrote the code to accommodate every little requirement elegantly and with proper abstractions and so on... I will say you would just end up with system so abstract and general, no-one would understand exactly how it is meeting those requirements. Because you would had generalized every special case (where it should've stayed a special case, and that's that). So in a way, the simple hacked-together awful program might actually make more sense than the elegant and grand abstract program. Because you can follow the hacked-together program, and you can't follow the arhitected program. It's this "abstractions all the way down", where you can hunt abstractions down for "how exactly does it do this one thing" all day, and then find out it's a little config setting in obscure .properties file that actually covers this one business case. (And if it was there right in code, you would be done in 5 minutes. But alas - it's a config option, so to change behaviour, now you must write all infrastructure to support another possible config option.) I say - bad code is just fact of life in real-world business. You should strive to clean it up, make it elegant, abstract and generalize... but really business just needs to to chug along. |
Equally, I don't think that the opposite end of 'hacked together' is some kind of AbstractAbstractFactoryFactory extravaganza - that's just a different kind of bad code. To me, good code is code that is simple for other people to understand, and takes basic precautions with respect to being not-too-brittle to change. Every so often, I find that once the code has received enough alterations, it needs a bit of TLC.