Best Practices

Search

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.

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.

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?

Updated: 2012/08/15

Contributions

" 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.

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.

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 ;)

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".

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 :-)