I know a few successful programmers, who have spent many years of their life writing software, and in that time I’m yet to see them try any other language or platform—many of them clinging to the tools they started with.

Despite a wealth of software to choose from, they stick to the tools they started with. “It’s so easy”, “I know what i’m doing” and other reasons keep them in a software monoculture.

I think if anything it will be a fashionable technology, like no-sql or non-blocking, that will tempt them into new domains. As much as I rail against fads, developers do get exposed to more technologies and ideas as a result.

Nothing else can prise them from their battle tested homebrew utility library, lovingly copied and pasted from one project to the next (Bonus points if the file is actually called ‘util’).

I’m not trying to accuse these coders of abandoning all desire to learn—but you don’t learn anything doing the same things over and over. Ten years of using a language doesn’t count for much when it’s the same year repeated ten times. Then again, learning to do something in a new language is unpredictable, and not always enjoyable.

Maybe they’d rather have something that works which can be delivered on time—and spend their time learning, taking risks, and having fun elsewhere.

Instead of only learning to program.

I enjoy reading programming blogs—bitesized chunks of wit and snark, with the occasional war story thrown in. Friendlier than a unix manpage, they are an essential part of the pop culture that surrounds code, creating celebrities, flamewars and fads. Joel on Software is one of the earlier and more successful examples in the genre.

Spolsky’s guerrilla marketing campaign established a template for many of those that followed—tell stories about interesting companies you worked for, talk about why your business practices are effective, all in an authoritative but informal tone. Most importantly, don’t forget to cherry pick from “The Mythical Man Month” and “Peopleware.” They may be notable books, but there is a generation gap — programmers who’ve learned almost exclusively from their browser — so it will always be new to someone.

As Joel on Software became dormant, one of his later rants captured the essence of programming blogs–

This review captures what’s been driving me crazy over the last year… (sic) an unbelievable proliferation of anecdotes disguised as science, self-professed experts writing about things they actually know nothing about, and amusing stories disguised as metaphors for how the world works. […] it all becomes insanely popular simply because the stories are fun and interesting and everybody wants to hear a good story. Spare me.

[…] Now, I am not one to throw stones. Heck, I practically invented the formula of “tell a funny story and then get all serious and show how this is amusing anecdote just goes to show that (one thing|the other) is a universal truth.” And everybody is like, oh yes! how true! and they link to it with approval, and it zooms to the top of Slashdot. And six years later, a new king arises who did not know Joel, and he writes up another amusing anecdote, really, it’s the same anecdote, and he uses it to prove the exact opposite, and everyone is like, oh yes! how true! and it zooms to the top of Reddit (source)

It’s weird to find one of the most damning critics of Joel on Software would be Joel himself. He’s had enough of programming blogs, all like his, while humbly taking credit for the genre. I don’t blame him for the storytelling, as he notes many will come after him, but many other programmers have come before.

In the same way that Joel’s first real job taught him many lessons about programming, Fred Brooks waxed on about shipping a mainframe operating system, and how his experience applied generally. Even Brooks’ latest book opened with a similar complaint to Joel’s, “There are too many Anecdotes in Software Engineering, Let me tell you about how I built a house.”

So much of Joel of Software revolves around anecdotes, it might as well be called “Hackers and Bakers”. Stories begin with a filth encrusted oven, and end with lessons on Project Management, GUI Design and Computer Security. One of his bread making stories stands out as an example of the writing Joel decries, where he makes a case for Hungarian Notation, his snake oil for web security–

Way back in September 1983, I started my first real job, working at Oranim, a big bread factory. […] After two months in the bakery, you learned how to “see” clean.

Code is the same way. (source)

Hungarian Notation, for those yet to appreciate the full horror, is a way of smuggling type information into a programming language. The key idea is to prefix every variable with a type, effectively writing in a programming language where you have to put a cast on every variable, except the compiler doesn’t check this for you.

There are two basic styles Joel outlines—Systems and Application. Systems Hungarian uses the implementation type, meanwhile Application Hungarian chooses to smuggle an abstract type. For me, both litter the code with verbosity—but for Joel, Apps is good and Systems is bad. He claims Apps Hungarian makes “Wrong code look wrong” and prevents cross site scripting attacks–

Making wrong code look wrong is nice, but it’s not necessarily the best possible solution to every security problem. It doesn’t catch every possible bug or mistake, because you might not look at every line of code. […] You instantly gain the incremental benefit that every time a programmer’s eyes pass over a line of code, that particular bug is checked for and prevented.

The foundation of his argument is that a programmer will mentally check a line of code every time they read it and perhaps hopefully they’ll notice the bug if you force them to be verbose enough. The so called security Joel touts is simply security theatre.

Today, cross site scripting attacks can be eliminated by the language runtime, if it is aware of the difference between safe and unsafe strings. Instead of using a naming scheme, use types, and unsafe code results in runtime or compile-time errors. Letting the runtime, instead of the programmer handle security, was quite the missed opportunity for his pet language Wasabi (An in-house coffeescript of vbscript).

Even Joel admits that tools that handle failure are preferable to burdening the programmer–

The way to write really reliable code is to try to use simple tools that take into account typical human frailty, not complex tools with hidden side effects and leaky abstractions that assume an infallible programmer.

Better tools exist now—Facebook’s XHP is a great example of extending a language to handle cross site scripting attacks, and making code simpler to write and maintain. Safety comes from forcing developers to explicitly say when they don’t want string escaping.

Hungarian Notation is a throwback to the past, justified then as a last resort when faced with poor languages and tools. I’m not tired of ancedotes yet, but I’m certainly tired of this one. You cannot secure your code with a naming convention, hungarian or otherwise.

The results of the last attempt to rebuild HTTP, aka HTTP “Next-Generation” or HTTP-NG make fun bedtime reading.

Let us go back more than a decade ago, when HTTP/1.1 was appearing. Lots of people were excited to make HTTP2, so they formed a group, called HTTP-NG. They set out to fix HTTP. Not to spoil the story, but you can probably guess what happened. They failed.

It started off sounding reasonable - let’s fix the transport issues, the parsing issues, and the tunneling issues. Let’s make it easy to multiplex over http, because routers suck—Let’s make http easier to parse, because it’s a bit of a clusterfuck—and work out how to tunnel things properly, because people are doing it anyway.

As a result, they decided to write a new transport layer, build a remote invocation framework for distributed objects, and then implement http on top of it. Simple!

The new transport layer was called MUX. As with many attempt to multiplex streams over tcp, they had to re-implement bits of tcp atop. (Notably, other unpopular protocols like BEEP continue in this great tradition). Simple!

The remote invocation protocol set out to unify ‘the type systems of COM, CORBA, and Java RMI’, on the basis 'this need not produce a terribly bloated result’. This now meant handling reference/value distinctions and distributed garbage collection. Simple!

Now they had unified the world of software, finally they could then implement HTTP really easily, atop this gigantic turd. Simple! If only it weren’t for those pesky “legacy” installations, we’d be living in paradise.

For some reason, implementing support for distributed objects, and multiplexing never really took off—Technical superiority hasn’t ever made a convincing argument for adoption. Especially when this superiority came at a high implementation cost for frankly little gain and no interoperability.

HTTP-NG attempted to solve the problem we had — how *should* http work — rather than the problem we face — how do we improve HTTP without breaking things.

Similar promises were made, with oauth to oauth2, html4 to xhtml, xmlrpc to soap, and rss to atom—Let’s make a new standard, but better this time. Similar consequences befell them too—Some failed to be adopted, others failed to dislodge their predecessor, and some just avoided making an interoperable standard.

The failure to replace a working system with a sophisticated one is so common, it has a name—The second system effect—although usually applied to products, rather than protocols.

For the current attempts at HTTP2, you can perhaps breath a sigh of relief. They can upgrade without breaking old code. They aren’t introducing distributed garbage collection. There is production code from more than one vendor.

It’s staring off so reasonably, what could go wrong?

I think there is an opportunity to make consumer software that doesn’t shit itself, or that if we don’t move to highly reliable software, we’re doomed.

“A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable”

With the advent of ‘multicore’ and 'cloud’ and the inevitable ubiquity of computing, we’re moving to a world where data lives on different machines, and processing happens across cores— failure is rampant and destructive.

For the existing real time developments, programmer time is cheaper than run time. it is better to make the programmer do more work than to have something fail. Almost everywhere else, programmer time is at a premium. It simply isn’t economical to develop reliable software.

I’d like to think that HFT will lead to popular adoption of real-time constraints and techniques, but I have the feeling it will end up like computer gaming, where fast is almost universally better than correct.

Another hope might be academia, but much of the focus is on program verification, rather than reliability. Well typed software will eliminate some failure classes, but it doesn’t give you robustness. Mainstream academia worries about writing correct programs over programs that handle failure. Paxos just isn’t as cool as Hindley-Milner.

Really, we don’t know how to write and maintain software, let alone reliable software, without throwing vast amounts of time or money at the problem. when we come up short we’re left with the inevitably bug-ridden fruit of our labours.

I don’t think we’re going to see a renaissance of reliable software, until software failures become expensive, or reliability is cheap.

Your post describes a ( ) protocol ( ) github repo ( ) manifesto ( ) kickstarter for a distributed social network.

Your idea will not work. Here is why it won’t work. One or more of the following flaws may apply to your particular idea.

( ) You think “if you build it, they will come”
( ) All of the other social networks with more users, developers, time, and money
( ) “Users want to own their data” is an ideology not a use-case
( ) Public keys are not a magic wand to make security issues disappear
( ) Social problems dominate the technical ones
( ) People use email for that

Specifically your design fails to account for

( ) Scale
( ) Adoption
( ) That popularity is a Distributed Denial of Service attack
( ) Malicious Denial of Service attacks can happen too
( ) Only supporting ASCII or Latin-1 is racist
( ) HTTP Caching and Load Balancing
( ) Timezones are a necessary evil
( ) So is Unicode
( ) NAT Traversal
( ) Federation exists already
( ) DNS is still centralized
( ) Cross-site-scripting and SQL Injection are not features
( ) Further fragmentation will not solve interoperability
( ) Spam

and the following philosophical objections may also apply

( ) Character limits are the QWERTYUIOP of messaging
( ) Your homebrew markup is a tragedy of regular expressions
( ) Your understanding of HTTP and Representational State Transfer, is as informed as a youtube comment
( ) If it can’t be used for piracy, it isn’t decentralized enough
( ) You are proposing a new central point of failure
( ) OAuth. Now you have two problems
( ) OAuth2. The SOAP of Authentication

Furthermore, this is what I think about you:

( ) Sorry, but I don’t think it would work.
( ) This is a stupid idea, and I am going to make fun of you on a centralized social network.
( ) I will enjoy watching your dreams fall into obscurity and regret. I have popcorn.

Many blogs claim to elcuidate a dichotomy of programmers—normally good and bad. Upon careful inspection, most of them turn out to actually dictate the following–

1. Programmers who are like me are good
2. Programmers who are not like me are bad

The assertion is that if you cargo cult their personality, you too can be a successful programmer. It isn’t always as obvious, more often the division looks like this–

1. Programmers who use my favourite language are good
2. Programmers who do not use my favourite language are bad

Sometimes they just imply good and bad, without saying it outright–

1. Programmers who share my political beliefs
2. Programmers who do not share my political beliefs

You can imagine the quality of debate that ensued from programmers arguing about code in terms of political strawmen.

Why do we do this? It’s easy and gets blog hits. Especially when the two choices are emotionally charged.

When viewing the world through this fragile mentality, the difference between good and bad programmers seems vast. Another classic division is the idea that some programmers are ten, twenty, or a million times better than the unwashed masses–

1. Good Programmers have magical super powers they are born with
2. Bad Programmers simply cannot ever become this good

Accompanying this fantasy, you will find terms like rockstar, ninja, founder, entrepreneur, all used in the same pre-pubecsent machoism that our industry is drowning in. Beyond smug assholes declaring it to be true, there isn’t a lot of supporting evidence.

The only supporting evidence for the “uberhacker” was a study on batch processing vs interactive programming, in 1960. On a handful of people, in a half hour session. The rest of the noise is untamed adolescent egotism.

Really, when managers talk about “A” programmers they mean people who will work long hours for little to no pay.

We’ve been repeating this myth endlessly. It’s destructive. It’s either repeated by idiots who believe they have nothing to learn from others, or repeated by learners to explain why they shouldn’t try to learn.

This myth has many forms, with many attempts to explain the magic power away in terms of some physical characteristics–

1. Programmers who have a penis are good
2. Programmers who do not have a penis are bad

If you believe in this in any way, it is highly likely that you are not only a terrible programmer, you are a terrible person too.

The divide is always tempting, everyone loves a simple answer to a complex problem. So are there two types of programmers? Probably not, but if I was to try, I’d say–

1. Programmers who know they will make mistakes
2. Programmers who think they will not make mistakes

Even this doesnt work, I’m a little of both—Sometimes I refuse to try, and sometimes I refuse to learn.