3 ms·

The problem with software is that it is too easy to get it working. If you would do completely stupid shit while designing an analog electronic circuit you woul

by stiff 12y ago

The problem with software is that it is too easy to get it working. If you would do completely stupid shit while designing an analog electronic circuit you would get completely stuck in your "inventions" very soon and would not be able to deliver anything working beyond the simplest stuff, the difficulty would just force you to adapt a sensible design approach or resign from doing any electronics in the first place. In software engineering, on the other hand, the kind of wankery presented here lives on for years because there is no reality check - as long as a group of people feels good about themselves inventing fancy words and "techniques" without putting in too much effort into anything of substance, fads of this kind can live on. They can even deliver products written in this manner and get paid, for the projects work, as far as most business projects are concerned, it is simply that the code is just awful to look at. Meanwhile, serious software from "firmware" for space shuttles, through huge game 3d engines, compilers, operating systems, to scientific software manages to get developed without having any need for this sort of thing. Somehow it's always the rather trivial software that gets those super-"architectures".

angersock 12y ago
All of your examples don't exactly make the point you're trying to make: Ask anyone who's had to debug game engine code, compilers, operating systems, or the worst of the lot, scientific code. Most of those systems would actually benefit from proper design and architecture, but people like you decrying their "wankery" have relegated such introspection to the dustbin. And that attitude is why software engineering is mostly a dark joke.
- ChrisGaudreau 12y ago
  That might be fine if the majority of software developers worked on game engines, compilers, or operating systems. But we're talking about Rails applications here.
  - angersock 12y ago
    Yes, Web applications are somehow magically exempt from sound engineering practices. If you want to make the argument that shitty Rails hairballs that don't scale aren't a problem, because they fulfill a business need and fill it quickly, I'll agree. That said, that's a business decision, not a technical one.
    - ChrisGaudreau 12y ago
      Every application can benefit from sound engineering practices. Creating a complicated monstrosity when you're not going to need it is not sound engineering practice. At least I don't think it is, but then again I don't consider myself an "engineer." Once again, Java is a great example. For over a decade, Java developers have piled on more and more "sound engineering practices." Maybe it's just me, but these Java applications are not easy to extend or modify in any way.
- timr 12y ago
  I've written more scientific code than most people here, and the OP is right: it's the last place you want wanker abstractions. KISS applies to scientific code in spades. The concepts are hard enough to get right without all sorts of meta-logic muddling your thinking. Only when applications are truly trivial (i.e. "boring") do developers go on architecture spaceflights to keep themselves entertained.
  - angersock 12y ago
    The best way to keep things simple is to keep them small and composable, right? Like, say, in the Unix way? I'm all for brutally-efficient and single-minded code in domains like mathematics or simulation modeling, where things like object encapsulation maybe don't make a great deal of sense (classic array-of-structs vs struct-of-arrays sort of thing). That said, keeping that stuff neatly boxed and then moving everything else out (say, file I/O, logging, whatever) into neatly abstracted boxes makes sense. More sense than most of the monolithic piles of Matlab and Java and C and Fortran I've seen, because people were rushing to finish a paper. But hey, it's not like the next generation of grad students has anything to do but spend long hours debugging poorly-documented and poorly-designed code, right? And it's not like there is any sort of commercial financial or reaction modeling software that needs to be anything other than inscrutable monoliths, right--you know, something which could actually hurt somebody physically or fiscally. Performance is king, after all. (Hint: people who sacrifice engineering and design for performance or simplicity deserve neither.)
    - timr 12y ago
      The choice is not "monolithic piles of Fortran" or abstraction hell...there is a middle ground. All of your comments on this thread seem to be predicated on the assumption that this blog post is an example of something good. It isn't. It's a complicated, overwrought non-solution to an imagined problem. Nobody here is arguing against abstraction, but abstraction needs to be used judiciously, and the best abstractions don't stray far from the application domain. It's a subjective thing that comes largely from experience, but you've likely gone off the path to enlightenment when you start creating ("hexagonal") meta-frameworks to create framework frameworks.
- Iftheshoefits 12y ago
  Abstractions and "proper design architecture" of the sort in this article have very little place in scientific code meant for the efficient study of complicated systems, at least. It usually gets in the way of what's important: performance and scientific correctness.

by stiff 12y ago

angersock 12y ago

All of your examples don't exactly make the point you're trying to make: Ask anyone who's had to debug game engine code, compilers, operating systems, or the worst of the lot, scientific code. Most of those systems would actually benefit from proper design and architecture, but people like you decrying their "wankery" have relegated such introspection to the dustbin. And that attitude is why software engineering is mostly a dark joke.

ChrisGaudreau 12y ago
That might be fine if the majority of software developers worked on game engines, compilers, or operating systems. But we're talking about Rails applications here.
- angersock 12y ago
  Yes, Web applications are somehow magically exempt from sound engineering practices. If you want to make the argument that shitty Rails hairballs that don't scale aren't a problem, because they fulfill a business need and fill it quickly, I'll agree. That said, that's a business decision, not a technical one.
  - ChrisGaudreau 12y ago
    Every application can benefit from sound engineering practices. Creating a complicated monstrosity when you're not going to need it is not sound engineering practice. At least I don't think it is, but then again I don't consider myself an "engineer." Once again, Java is a great example. For over a decade, Java developers have piled on more and more "sound engineering practices." Maybe it's just me, but these Java applications are not easy to extend or modify in any way.
timr 12y ago
I've written more scientific code than most people here, and the OP is right: it's the last place you want wanker abstractions. KISS applies to scientific code in spades. The concepts are hard enough to get right without all sorts of meta-logic muddling your thinking. Only when applications are truly trivial (i.e. "boring") do developers go on architecture spaceflights to keep themselves entertained.
- angersock 12y ago
  The best way to keep things simple is to keep them small and composable, right? Like, say, in the Unix way? I'm all for brutally-efficient and single-minded code in domains like mathematics or simulation modeling, where things like object encapsulation maybe don't make a great deal of sense (classic array-of-structs vs struct-of-arrays sort of thing). That said, keeping that stuff neatly boxed and then moving everything else out (say, file I/O, logging, whatever) into neatly abstracted boxes makes sense. More sense than most of the monolithic piles of Matlab and Java and C and Fortran I've seen, because people were rushing to finish a paper. But hey, it's not like the next generation of grad students has anything to do but spend long hours debugging poorly-documented and poorly-designed code, right? And it's not like there is any sort of commercial financial or reaction modeling software that needs to be anything other than inscrutable monoliths, right--you know, something which could actually hurt somebody physically or fiscally. Performance is king, after all. (Hint: people who sacrifice engineering and design for performance or simplicity deserve neither.)
  - timr 12y ago
    The choice is not "monolithic piles of Fortran" or abstraction hell...there is a middle ground. All of your comments on this thread seem to be predicated on the assumption that this blog post is an example of something good. It isn't. It's a complicated, overwrought non-solution to an imagined problem. Nobody here is arguing against abstraction, but abstraction needs to be used judiciously, and the best abstractions don't stray far from the application domain. It's a subjective thing that comes largely from experience, but you've likely gone off the path to enlightenment when you start creating ("hexagonal") meta-frameworks to create framework frameworks.
Iftheshoefits 12y ago
Abstractions and "proper design architecture" of the sort in this article have very little place in scientific code meant for the efficient study of complicated systems, at least. It usually gets in the way of what's important: performance and scientific correctness.