Is it just me or did this not age entirely well? I really appreciate Joel’s writings, but in a kind of very specific way .Net did actually turn out to be the big deal it set out to be, along with Java. Modern spreadsheets are just message-passing machines, and somehow Messaging companies are gigantically valuable. Yes, astronauts are expensive, perhaps overcelebrated and often wrong… but somebody has to do it right!? I for one am glad we’re not still emailing Master-Spreadsheet-FINAL(1)(1).xls back and forth to get things done. I rather like millennials like Ryan Dahl that saw the potential for Javascript to be more than a browser scripting language. I may have even been something of an astronaut myself (an “idea man”… my team would jeer)- but I’ve come down to the earth and dig my hoe into the soil these days. I think we’re better off with some good astronauts out there, at least sparingly.
.Net did actually turn out to be the big deal it set out to be,
.Net and c# have evolved into a great general purpose framework and language but the original lofty hype around .net was about turning everything into soap web services for b2b messaging with automatic discovery and blah blah blah and that never happened. JSON and Rest waltzed in and (somewhat) did that organically without the hype.
XML is a great example of what Joel's talking about. It turned out to be moderately useful but was hobbled by all the over-architecting in its early days.
Joel isn't arguing against progress in general here, he's arguing against over-architecting.
I think some of the technologies he lists are just bad, not over-engineered. Usually "complicated" and "bad" are signs of not doing enough engineering; just shipping what you have and bolting on haphazard extensions as people think of them. XML was that, and so were XML-RPC and SOAP.
You can see this happening with the newer technologies. JSON has a lot of quirks, like not having binary or integer types. So people have bolted those on. JSON doesn't have schema definitions (which are nice if you, say, want to generate code to talk to an API), so we're bolting those on (JSON Schema, OpenAPI, etc.) Admittedly, it's all a lot easier to understand this time around.
To some extent, I'm not sure if we as a field learn from the past, or just reinvent it every 15 years and do a little better accidentally. (Remember the PC revolution, and how you wouldn't have to connect to a big mainframe to do computing? That revolution died and now we carry around $1500 dumb terminals in our pockets, while all the software runs on a mainframe!)
>SON and Rest waltzed in and (somewhat) did that organically without the hype.
This is a perfect description of how it happened, and how practicality trumped the bombast of the people pushing SOAP and what later became the terrible framework that is WCF (whatever happened to Don Box? He was all over the place for a while).
Biztalk also lands nicely in the 'conceived and designed by astronauts' camp.
He isn't talking about all architects, architecture astronauts are specifically the kind of architect who no longer writes code. The guy who wrote node.js clearly still coded when he wrote it, and so on, so your examples aren't architecture astronauts.
Edit: And if we take your examples, the Architecture Astronaut would be the person who says "We should use node.js in our backend, it will solve all our problems!", not the person who wrote node.js.
Fair. The most (semi-recent) controversial astronaut I can think of right now might be Martin Fowler and his work on event sourcing + CQRS. I don’t know if he writes code or not, but I’ve heard a lot of angst from the people who have adopted those patterns. I made a small system using those ideas built on AWS Event Bus and it generally worked quite well, but I can see where making that pattern the law in a larger setting could be excruciating.
The system processes a stream of log events and triggers lambda functions that each handle various API calls in a user provisioning flow. Some of the tasks could run independently of the others, and those that depend on successful completion of a prior task are triggered based on a pattern-matched log emitted from the dependent lambda functions. Failure on any of the functions pushes events to a shared dead letter queue. Everything needs to be idempotent and use the original source timestamp field to be handled correctly. We could have achieved the same business logic with Step Functions (or any number of approaches, with the requirement that no new servers had to be managed) but Event Bus had a ready-made integration with an event source that we needed, and was a lot cheaper to operate. I can't really speak in depth to the gripes of others, but I can say that tracing and debugging was hard until we made it easy. If we had to add a lot more interdependent business logic to the system it would have probably become difficult to maintain.
Trying to choreograph dozens of lambda functions is one of those solutions that’s more hype than sense. AWS pitched lambda for one-off video transcoding, then overzealous folks took it way way too far.
FWIW, event driven is not event sourced. AWS Event Bus is neither persistent nor ordered which makes it not fit for event sourcing unless the lambdas were only an ingest for Kinesis or the like. For example: how would consistent replay be accomplished?
It's so easy to shoot yourself in the foot with CQRS...I have yet to see co much duplication in an otherwise clean codebase like I saw in the single CQRS I worked on.
On the contrary, I think this has aged really well.
Look at this for example:
> A recent example illustrates this. Your typical architecture astronaut will take a fact like “Napster is a peer-to-peer service for downloading music” and ignore everything but the architecture, thinking it’s interesting because it’s peer to peer, completely missing the point that it’s interesting because you can type the name of a song and listen to it right away.
He was exactly right. Now you can do the same thing on YouTube: type the name of a song and most of the time it will come up right away. And that's what matters the most.
> All they’ll talk about is peer-to-peer this, that, and the other thing. Suddenly you have peer-to-peer conferences, peer-to-peer venture capital funds, and even peer-to-peer backlash with the imbecile business journalists dripping with glee as they copy each other’s stories: “Peer To Peer: Dead!”
Crypto comes to mind. Crypto is astronaut crack. Distributed ledger astronautery for some. Weird economics astronautery for others. Meanwhile, the "listen to song" feature of crypt being "I can make money with this." Eventually we'll have CB crypto with reversible transactions.
I also appreciate a lot of what Joel has written; without fail, it's always a little insightful and thought provoking. I don't think it's so much that it didn't age well... but it started out fairly short-sighted or got lost on the way.
The example of generic file support seems a bit of a stretch for example. There's inherently nothing wrong with adding more support, but the contrived example conveniently meant the loss of a feature. Of course backward steps are bad... and why certain 'contracts' are established.
I think he went into it wanting to make a different point - delivery in the end matters more than design. This, I've [somewhat begrudgingly] learned, I agree with. He's probably gone on to make a post just like this that changed my views.
I don't think he gives credit to these astronauts and what they have to achieve, and the flexibility it demands. These are the dreamers, and sometimes you have to keep them from wandering too far. Other times, you might want to see where it goes.
The real world isn't FIFO. You can go with the short term safe plan while you try to find a clever solution to never have $design_problem again, or bolt on the latest feature.
It's great that he can imagine his new favorite gizmo, but it has to happen somehow. What's more, the lessons learned along the way tend to be useful anecdotes elsewhere.
Like Mr. Savage implied (I won't try to accurately quote), what makes science not screwing around... is writing it down.
> .Net did actually turn out to be the big deal it set out to be
At the time (2001) .Net was the brand for a vaguely defined all-encompassing Microsoft initiative - something about connecting everything. The .net framework was just one piece of this, there were also SOAP services, a global identity system and various other stuff. See for example this old article: https://www.computerworld.com/article/2596383/update--micros... :
> For end users, .Net provides a sparse, browser-like user interface without any menu bars. A key concept in the new user interface is the "universal canvas," which Microsoft said eliminates the borders between different applications. For example, spreadsheet and word processing features will be available inside e-mail documents. .Net also will support handwriting and speech recognition, the company said.
It is clear nobody (even in Microsoft) had any idea what .net was supposed to mean!
This branding obviously failed, so .net was narrowed to just describe the development framework.
I tend to agree with you: this did not age well. You know what is just as bad as architecture astronauts, wunderkinds ranting about how other smart people are stupid. This whole post feels like the aftermath of some late night argument that probably he should have just deleted in the morning. Not to mention the subtle digs in the pics that he conveniently forgot to caption: is that the MIT campus and two pics from Harvard? If it was revealed that this rant was related to some collegiate affair that only three people in the world remember, I wouldn't be surprised.
if you replace the technologies with tech-du-jour it's pretty much the same thing - kubernetes solving all of your deployment and system managment needs (except for, you know, managing or understanding kubernetes itself), json or yaml being the be-all-end-all for data formats (until you need comments, etc), 'cloud native', 'serverless', etc.
these are all tools not solutions but people keep pretending the tools are the solution. That's the 'astronaut' part - off in space and not grounded to actual user requirements.
> I rather like millennials like Ryan Dahl that saw the potential for Javascript to be more than a browser scripting language.
Not to take away from that achievement, but he wasn't the first one to implement this idea.
The infamous ECMAScript 4 was supposed to be a more general purpose language. Also there were previous attempts at roughly the same in the form of e.g. Rhino[0].
