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".
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.
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.
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.)
It usually gets in the way of what's important: performance and scientific correctness.
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.
I have a deep dislike for overabstracting a system merely because someone has a list of hypothetical use cases. And make no mistake: it is always about supporting the hypotheticals, never about supporting what's actually really needed by the system.
Down this road lie dozens of layers of abstracted factories and strategy implementations which exist just in case someone wants to "persist" a relational object over a serial printer line. YAGNI.
Is this because the majority of the community is self thought? Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)?
The constant negative reaction to anything a little more complex is frankly laughable.
> Or is this because most of you only build MVPs which are mostly CRUD apps (and therefore don't know from first hand experience the benefits of a modular system)?
This is what I use Rails for, and its entire reason for existing. It's a set of conventions for CRUD apps, not a general-purpose language for building distributed databases and coordinating space missions.
The problem with these complex software architectures is that they're decoupling Rails from the database, but why in the world would you want to do that? Rails is great because it manages the the meeting point between web requests and relational databases in an elegant, repeatable, commonly-understood way. If you need a complex, general-purpose system that only sometimes will talk to a database for persistence, why in God's name did you use Rails?
Come on. Nobody is defending "overcomplexity", which is by definition a rather indefensible position. The issue is the frequent arrogance exhibited here by commenters who insist that certain commonly and successfully used design patterns have no place in the world.
To get your tests to run in < 5ms
> but why in the world would you want to do that?
Build better software faster
Because it is actually a very good, mature application server with lots of sane defaults and good, mature plugins, even if you aren't using a database. Basically, people are interested in using it for more complex applications than you are, because lots of its conventions are still quite good for those applications, even if it makes sense to reject or reconsider some other conventions that don't work quite as well.
The lighter-weight frameworks we have now in languages like Ruby and Python do have abstraction to deal with changing out bits of technology, but they've reached a point where they abstract only the things that experience has shown are likely to change, and support only the changes that are likely to happen.
Nobody in the real world is suddenly going to decide to "persist" their employee records to volatile local memory instead of something permanent like a database. Introducing new layers of abstraction -- with the attendant increase in complexity and potential abstraction leak -- to support those types of contrived hypotheticals is how overabstracted systems like J2EE come to be.
> The lighter-weight frameworks we have now in languages like Ruby and Python do have abstraction to deal with changing out bits of technology, but they've reached a point where they abstract only the things that experience has shown are likely to change, and support only the changes that are likely to happen.
So is abstraction always about supporting hypotheticals or only when you're exaggerating?
Implementing a switch statement and hardcoding references into 10,000 line modules with different behaviour (e.g. different rules for different jursidictions) is untestable and unmaintainable. Abstraction has value in these scenarios. And just like everything, it can be abused (e.g. abstracting over 3 scenarios with 5 lines of code in total to support a particular once off business case that is going to be discarded after running once). That doesn't mean abstraction no longer has value.
Furthermore, languages with static type checking require different styles of testing and coding (e.g. abstraction) vs languages with dynamic type checking. Neither approach is universally better for all problem solving. Criticizing features of well designed code in one language that wouldn't be necessary in code written in another language is like criticizing a car for having wheels given that boats do fine without them.
I wouldn't say that always happens. It often happens when a 500-word blog post suggests effectively re-architecting a mature, successful framework like Rails. Let's think about why such a post is problematic.
Rails has evolved over quite a few years in response to actual needs on the ground. Tremendous amounts of ink have been spilled, and tremendous amounts of brainpower have been expended to create a mature framework like Rails (or similar frameworks).
Despite the battle-tested history of the framework, so many of these architecture blog posts imply that Rails' architecture is somehow insufficient. And then propose to fix that architecture, spending, say, 500 words explaining the idea. There's hardly any discussion of the idea's wide-ranging implications, of the trade-offs, or of the conveniences that are lost. If this idea is so good, why hasn't it ever found its way into Rails, even in diluted form? Why has the Rails team built the architecture they have, instead of yours? (Hint: They probably have a good reason.) Do you have strong evidence that your proposed architecture will serve me better than the one that I've been using successfully for years?
All that being said, I have no problem with idiosyncratic Rails techniques that only step a little outside what the framework provides. For example, service objects. Used appropriately (which usually means sparingly), they can help with organization without fundamentally warping the Rails app. Using a few service objects is a departure similar in magnitude to writing your JS in TypeScript instead of CoffeeScript. It's not built into Rails, but it doesn't really change any of the core concepts either.
https://plus.google.com/+aerotwist/posts/1QhcnQizuPc
description: "Convenient proxy factory bean superclass for proxy factory beans that create only singletons."
http://docs.spring.io/spring/docs/2.5.x/api/org/springframew...
I'm reminded of the various Evolution Of a Programmer jokes which end with the master programmer writing the same code as the beginner programmer.
It does seem to be a lot of abstraction. Of course, with abstraction comes flexiblity, that's the point, I get it. But with (some kinds? all?) abstraction also comes complexity and cognitive load for the developer. If you're not careful, you end up in Java FactoryGeneratorFactory land.
(I hope the next step in the 'hexagonal architecture' isn't using an XML file to specify all the linkages and concrete classes in use. How else do you specify what concrete @db etc your controller is instantiated with?)
I find it a bit odd that the community who has railed Java hard suddenly came up with something more complex than... gasp... the solution in Java-land.
What community is it that you think has "suddenly" come up with what solution that's more complex than what "the" solution in Javaland? I'm not even sure what you're talking about. There are of course many solutions in Javaland, naturally, and in every other code land.
I think engineering code, especially code shared between multiple developers/installations, is a constant tension between simplicity and abstraction/flexibility. It's sometimes possible to optimize both, but it requires a lot of skill and a lot of domain experience, and domain experience especially seems to be under-valued and under-present in the current environment. (Plus if the domain changes fast enough, nobody ever has enough domain experience!)
I think individual developers, as well as teams and communities (language-based or industry/domain-based) often swing from end to the other. This legacy thing is too complicated, let's start over with new principles to keep it simple! This simple thing isn't as flexible as I want, let's add in some abstraction to make it possible to do what everyone needs; then do it again; then do it again; then start over at 0.
In practice the whole falls apart after a week or so because I forget to do things the right way or because I don't feel like processing my 'inbox'...
Instead, I seem most effective when I write down my top three tasks of the day on a piece of paper.
Maybe I get that feeling because I've mostly experienced companies where testing didn't really seem to have much of an effect. Whenever I asked about this lack of efficacy, the answer was usually "that's because we're not implementing it completely!"
Which is exactly what I hear (and suggest) whenever I or someone else falls off the GTD wagon.
Am I completely wrong about that feeling? I mean that as an honest question, as I truly don't want to be negative and I'm way to inexperienced to be cynical about these things :-).
http://webcache.googleusercontent.com/search?q=cache:0-I-y0x...
The issue I have with posts like this is that they are decidedly NOT just about thinking up wild new designs. Instead, they claim that these designs are somehow BETTER. Unless you can give me a real world use case, I won't believe you.
It's way more fun and tastier to make your own meals.
