4 ms·
I don't know about programmers-vs-scientists-vs-engineers-vs-… and all that stuff (basically, these are just some words and I can question the fact they mean so
by krick 13y ago
I don't know about programmers-vs-scientists-vs-engineers-vs-… and all that stuff (basically, these are just some words and I can question the fact they mean something at all), but I agree with the main point of the article. Or the way I interpreted it, anyway. That is "road to hell is paved with good intentions". I have to deal with it on daily basis. There is some legacy code in the project considered to be bad and always referred to as that. And, well, yeah, it is bad. But when I have to deal with some new architectural marvel of some my colleagues, who are considered to be good and actually are pretty bright adequate people, then I often think that that "legacy code" was actually easier to deal with before "refactoring". Exactly for the same reasons author mentioned.
I mean, some god object with multi-screen functions with 9000 ifs and non-escaped SQL is ugly and horrible, but in fact pretty simple to debug, comparatively easy to understand and often even easy to clean up a little bit without breaking anything. But some metaprogramming-reflection-abstract-class-GenericBuseinessObjectManagerProviderFactory-10-levels-of-inheritance is not. It even might be not ugly, it's often clever and somewhat elegant. If you know how that works. But if you don't (and for starters you always don't, unless you are author of that elegant solution) it takes you hours of pain and bloody tears before you can understand what happened here and finally make changes you wanted to.
I actually believe that this is a problem, because it isn't something that some person does, because he is dumb. He's not! It's the culture, that overly praises clever techniques and "elegant" solutions, while spreading the myth that "not sophisticated enough" means "bad". It's not! "Hard to understand" is "bad". Nobody really needs "cleverness" and "elegance", in the end of the day, they need something that works and is easy to understand and develop further. And the truth is that something "not sophisticated enough" (even if it's goto, copy-paste, mutable variable, global object, whatever) is often easier to understand than something sophisticated one.
- userbinator 13y agoI've been faced with this countless times too and I think the problem is a culture that equates complex and abstract solutions to elegance, when we should really have one that equates simplicity and conciseness to elegance. By simplicity I also mean considering the solution as a whole, not the false simplicity of refactoring everything into one-statement-methods.
- buzzybee 13y agoWhen I've taken this thought to its extreme, Chuck Moore's ideology around Forth makes total sense: If a problem is only going to be solved in a complex, Byzantine fashion, it's the wrong problem. Walk away from it. Solve a different one. Quit the job. Reconsider your lifestyle. And most people aren't going to be able to consider it seriously on that level. The monstrous systems are there because everyone involved has collectively agreed that whatever is justifying the problem is so important that it's OK to let the resulting system grow monster-sized and swallow everyone up. On that basis the only thing anyone can hope for is a painkiller to make the monster a little less soul-crushing.
- makomk 13y agoThat reminds me, I was trying to code something using Twisted Python the other day and regretted it for exactly that reasons. Abstraction layers and factories around factories around abstractions, oh my. What's more, despite those abstractions (or more realistically because of them) it wasn't easy to replace the underlying XMPP transport with a different one. I wound up having to replace a constructor and an undocumented internal method so I could substitute several of the layers with different implementations someone else had written, again in a way that was documented precisely nowhere.
- stcredzero 13y agoPeople forget when writing tools and libraries: easy things easy, hard things possible. Instead, people often aim for "can do everything possible in the spec, because I am awesome!" Years ago, we had to go from a Sun JMS library to one from Weblogic. I had to instantiate a half dozen objects just to send a message. In the Sun one, you used one API call to authenticate and connect, and another to send. Easy things easy, hard things possible. Otherwise, you're guilty of bad design.
- collyw 13y agoThat reminds me of writing to a file in Java versus writing to a file in Perl / Python. (Its been a while since I did any Java, I hope it has improved since then).
- heurist 13y agoI agree with the author to the extent that you should keep the target audience in mind when writing code. I disagree that it means not using best practices. If you spend 30 minutes to an hour explaining objects or other conventions to your academic colleagues you'll all be better off when reading and writing code. It also sounds like an issue of developers being overly clever in general. Clever does not mean elegant and in my experience cleverness usually backfires for the reasons listed in the article. Elegance makes everything look easy.