That Steve Yegge is really good at starting conversations. Everyone including Steve thinks his essays are way too long, but they’re insightful and erudite and funny. His most recent outing, Notes from the Mystery Machine Bus, is all of those things, and worth plowing through to the end. It’s also more or less completely wrong.
Wrong Why? · Because, after providing a framework to help think about competing software technologies, Steve says, essentially, “It’s like politics, we’re not gonna all just get along, use whichever suits you”. But damn it, this is an engineering discipline, and for most projects we undertake, there should be some consensus Best Practices in terms of tools and architectures; where there aren’t, that’s a bug. In my profession as a whole, I mean.
Related · Steve’s rant provoked Yossi Krenin to emit What “Worse is Better vs The Right Thing” is really about, another long, valuable, mostly-wrong (albeit for different reasons) essay.
Things come in clusters; also in this one is Andy Boothe’s Should I Use ORM Or Not? Sure. (Andy’s blog’s title space reads: “SIGPWNED / killall -PWNED n00b”. Uh, OK.)
Liberal/Conservative · That’s Steve’s premise. That there’s this great big single axis that analogizes well with the way we think about politics, and that you can slot technology choices in along it. Assembler: Liberal! Erlang: Conservative! And so on. Steve’s over on the left, he says.
He’s also out of the mainstream, since he works at Google scale and not particularly on mobile. The big wide center of software development, these days, is medium-to-large apps and their mobile front-ends.
Best Practices · I claimed that they exist, independent of your software politics. To illustrate my point, here are a few; by way of example, I mean, not a comprehensive list:
When you’re building a Web app at less-than-Google scale, and time-to-market is important, the use of traditional “Enterprise” frameworks involving Java EE, Spring, and Dependency Injection is wrong. The use of dynamic-language-based Web frameworks is right.
Building systems which require a great deal of concurrent processing is to be avoided. If concurrency is required, mutable global state is wrong. The use of functional-programming techniques is required.
Rapid iterative deployment of systems, with each release focusing on a very small number of features is (when feasible) a sound methodology.
-
Static typing’s attractiveness is a direct function (and dynamic typing’s an inverse function) of API surface size.
Dynamic typing’s attractiveness is a direct function (and static typing’s an inverse function) of unit testing workability.
Obviously there are more. I’m not sure whose job it is to collect & curate them. Unfortunately I’m entirely out of touch with how Software Engineering is being taught these days. I wonder how much they think about Best Practices, and what they think they are?
Contributions
Comment feed for ongoing:
From: Kevin Marks (Aug 15 2012, at 16:24)
Have you seen: http://www.12factor.net/
and Aaron's http://pokayokeguide.com ?
[link]
From: Chris E (Aug 15 2012, at 16:41)
" But damn it, this is an engineering discipline, and for most projects we undertake, there should be some consensus Best Practices in terms of tools and architectures; where there aren’t, that’s a bug. In my profession as a whole, I mean"
It really isn't an engineering discipline. There are a few things that approximate engineering, but the discipline as a whole is definitely not an engineering discipline.
[link]
From: Gaurav Sharma (Aug 15 2012, at 17:58)
Engineering shouldn't drive what people do. People should drive what engineering does.
All kinds of arguments can be made here, based on differing contexts, but I think you'll agree that the latter point is ultimately more important than the former.
[link]
From: Josh Koenig (Aug 15 2012, at 18:22)
"It really isn't an engineering discipline."
I had a similar reaction. While I like the idea of promoting GOOD practices, and I agree with your suggestions here in general, I think there's far too much subtlety and subjectivity — what scale you work at, who you work with, what your resource constraints are, etc — to really ever say there's one single TRUE way to do things.
Most people use the term "Best Practices" to refer to "generally accepted norms for how things are done correctly." That's not about determining right from wrong, and more about differentiating between risky and sound. It's also an inherently fluid thing as over time the problem-space will evolve.
I think there's a lot to be said both to looking at motivational source (risk tolerance, etc) as a way of understanding design imperatives, as well as seeking axiomatic principles that can be applied across multiple problem sets. Kudos to both you and Steve (and others) for moving the conversation forward.
[link]
From: arcandros (Aug 15 2012, at 23:48)
There always seems to be a reaction to the Engineering vs Craft where software is concerned.
In my experience trained engineers (I myself am an Electrical Engineer) that earn their living in software fall in the "it's engineering" category, everyone else fudges.
Maybe it's because when you actually train as an engineer you learn that nothing is clear cut. You calculate within a given set of tolerances and if you're mainstream you don't have to worry...much. And because the bleeding edge in the material world causes actual bleeding not many of us get to see or hear about it.
Curiosity's lander is an engineering marvel, but I don't think that anyone *really* knew if it would work.
On the other side, with the parallels drawn with structural engineering, people tend to take into account the state of structural engineering *today*, which to my mind is a very different point in the evolutionary path than the point where software engineering is today.
Software engineering at the moment relies more on empirical methods than codified formulas and practices, something structural engineers did a century and a half ago.
The pace of change in software far outstrips anything else wether we like it or not. Enjoy the romantic pioneer years of software development where the boundaries for expression are loose and wide ;)
[link]
From: Andy (Aug 16 2012, at 08:00)
Enjoyed the post, but I don't think those posts were really in reaction to Steve Yegge's posts. In particular, mine (via sigpwned.com) was not; last weekend was just my first free weekend in a while, and that's a post I'd been meaning to write for a while.
With respect to "clustering," perhaps these posts are always happening, or maybe it was just coincidence. But not all ideas are born of Steve Yegge's blog, excellent though it is.
Also: SIGPWNED is a play on Unix signal names, which traditionally start with SIG (SIGKILL, SIGHUP, ...), and one can send a signal by name to all processes of a given program using "killall -SIGNAL program".
...I am not a clever man.
[link]
From: Vladimir Stepanov (Aug 16 2012, at 12:27)
That this is an engineering discipline doesn't mean this is not subject to polictics (which in turn does have some best practices, arguably) :-)
[link]
From: Michael Lawley (Aug 19 2012, at 01:44)
Well, it's an engineering discipline in as much as a building a bridge and then evolving it over time with new features, etc etc is an engineering discipline.
I think this evolutionary aspect (or just plain change) is a key aspect of what's going on here. Going back to the Worse is Better dichotomy of Gabriel, the reason why The Right Thing doesn't (usually) work is that what is Right changes - software is never "done" (except, of course, TeX :-)
[link]
From: Walter Underwood (Aug 27 2012, at 21:52)
It is an engineering discipline, but it is an overconstrained problem with too many dimensions for a closed form solution.
So, we need to use, as you suggest, best practices.
Every few years I re-read Butler Lampson's "Hints for Computer System Design": http://research.microsoft.com/en-us/um/people/blampson/33-hints/webpage.html
[link]