One should give credit to Joel for correctly identifying the issue: great thinkers excel in abstract thought. Many of the comments here, however, seem to misunderstand his point about the propensity of creative minds to continue the refinement process and "not knowing when to stop". One (codeulike) apparently thinks simply being "bored" is what drives abstract thinkers. Let me assure you that is not the case, nor is it an inability to code. Many architecture astronauts started out as wiz coders.
Now let's review the gifts given by said astronauts - I'll limit to 2 examples but there are more:
- LISP is the mind product of a software astronaut.
- UNIX ("everything is a file") is the product of software space exploration.
My advice to serious young software engineers is to not accept mediocrity and imprecise thinking as acceptable standards for their chosen vocation. This cult of celebrating mediocrity in software design is a transient phase (20 years to date) and it is mostly a side effect of the introduction of facile soap boxes via the internet and blog sphere. When the dust settles, deep thinking and an ability to conceive powerful abstractions will yet again take center stage.
I don't interpret Joel as saying 'never do architecture'. I interpret him as saying something more like:
- If your goal is to create great new architecture, that's fine, go for it.
- But if your goal is to ship a product to customers, on a tight schedule – say, you are a startup trying to get an MVP out the door before the end of your runway – then you should probably not be doing more than a fairly minimal amount of architecture, and you should beware of the temptation to do so.
Note that both your examples were created by people employed by large, wealthy organizations (MIT and AT&T respectively) that could afford to give them plenty of time to explore interesting new ideas. That's a great situation to be in, the world would be a better place if we put more people in that situation, and if you are in it, then you should take advantage of it. But if you are unfortunately not in it, then you should be aware of that fact.
Isn't UNIX a clear example of people not engaging in architecture "astronaut" behavior? It was designed to be as simple as possible - in stark contrast to Multics.
I thought UNIX was supposed to be an example of worse-is-better philosophy which is in contrast to architecture astronauting?
But you may have a point with "everything is a file", and I wouldn't say that pattern have been entirely successful outside of actual files. I'm inherently skeptical towards any "everything is a..." philosophies. They tend to look good on paper but become ugly when they hit the gnarly real world.
> One (codeulike) apparently thinks simply being "bored" is what drives abstract thinkers
This is a pretty huge leap from what the commenter actually said, which was:
> I'll tell you what though, if you have a programming task that you find boring, over-engineering it and over-architecting it can make it _so_ much more enjoyable.
It seems you've misinterpreted many of the comments. People aren't upset about any kind of architectural design, only where it crosses a hard-to-define threshold into "over-architected". This is pretty hard to quantify exactly, but it is entirely likely you, codeulike and the rest would have an identical threshold where you'd say "you've gone too far ..." on some design.
Well, Joel first talks about 'great thinkers' and then about 'smart thinkers'. The latter kind seems to me a failed instance of the former kind. The architecture astronaut is a failed kind of thinker who is now inflicting his failure on all of us by actually never getting anything useful done while masquerading as a great thinker. There actually are great thinkers in history but they did not invent RPC protocols while at the same time thinking this would somehow be a technology revolution.
> One should give credit to Joel for correctly identifying the issue: great thinkers excel in abstract thought. Many of the comments here, however, seem to misunderstand his point about the propensity of creative minds to continue the refinement process and "not knowing when to stop". One (codeulike) apparently thinks simply being "bored" is what drives abstract thinkers. Let me assure you that is not the case, nor is it an inability to code. Many architecture astronauts started out as wiz coders.
I think you are just reading something that's not there.
> My advice to serious young software engineers is to not accept ''m and imprecise thinking as acceptable standards for their chosen vocation.
Hmm? What straw man are you attacking?
One problem is, many if not most engineers work in corporate environments where they have to deal with expectations and deadlines. Mgmt may perceive reimagining a system to be a risky long-term bet and its tough to persuade them of the benefits. In their defense their hesitation may be justified. I hate crappy hacks but at the end of the day there's a reason why they get piled on so much.
So I guess the question is - what's the best way to scope and evangelize a 'moonshot' project? Or should you just shut your trap and go join a startup?
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.
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.
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.
> When you go too far up, abstraction-wise, you run out of oxygen.
What happens if you don't go far enough up, abstraction wise?
You end up repeating yourself - everywhere. You end up with globals everywhere. You end up with God Classes. You end up with epic-length functions nested 15 levels deep. You end up with primitives trying to do the job that well-crafted data structures, named using the terminology of the problem domain, should be doing.
It's odd that the author rails against "astronauts" without addressing the very real motivations that lead to good architectures. Like all design, there are tensions in software development, and navigating the forces pulling you in opposite directions regarding architecture is one of the most important contribution you can make.
It's also odd that the author never calls out specific architectures that are the work of astronauts, just "the stupendous amount of millennial hype that surrounds them." He seems to hint in the introduction that CORBA is (was) one of them, but even that reference is pretty vague.
I would rather work with a codebase that has too little architecture than too much.
When the architecture is underdeveloped, it only takes somebody with a little more experience to fix the problem using incremental refactoring. But when astronauts have run wild with too many abstractions, it can be incredibly difficult to unravel them, especially if you don’t have the original developers’ help.
Joel's criticism targets PEOPLE not IDEAS. See the blog post title. There's nothing wrong with abstractions as an idea. The issue is when folks apply them in inappropriate and unnecessary ways.
When a smart, motivated, and caring person programs a computer then sensible abstractions will naturally emerge. A complex proprietary formula will not be copy-pasted because of course that's a bad idea. These judgement calls are important!
Globals are not always bad. Some data is truly global and should not be instanced, so to speak.
God classes are not always bad. Sometimes it's important to isolate experimental behavior from everything else and get it done quickly. Throw it into a class, throw the class into a file, mash a bunch of code in there, and test it out. If it works out then refactor it.
Primitives are not always bad. Data structures are not zero cost! The amount of times I've seen a "well crafted" (???) data structure tank performance by orders of magnitude is just sad.
> It's odd that the author rails against "astronauts" without addressing the very real motivations that lead to good architectures. Like all design, there are tensions in software development, and navigating the forces pulling you in opposite directions regarding architecture is one of the most important contribution you can make.
The context of the early 2000s was peak object oriented programming, uml, xml. technologies like corba were just symptoms of all the praying at the altar of software architecture.
> What happens if you don't go far enough up, abstraction wise?
Or you end up with a flat hierarchy of isolated modules that can do one thing and one thing only but can do it well.
Architectures are what can't be changed easily and it is easier to change what is small. Architectures that try hard to accommodate every case always end up getting in the way of everything.
You are conflating architecture with abstraction. Architecture is design, the map to a solution. Abstraction, however, is the distance that the architecture sits from the system's reason for existence.
I've found more usefulness in being pithy than in being prolix.
If you don't go far enough up abstraction-wise, you probably either don't have a good product or aren't solving anything profound. These 'high level' solutions are attractive to investors because they want 'napster for everything' or 'the iPod for your kitchen' or 'Sonos for your bathrooms' et ad nauseum. They're attractive pitches that make the likes of Mark Cuban's ears perk up. Whether or not you can sell them in the long-term, well, that's a different story. But these 'architecture astronauts' are the ones who get all the VC funding and grant money.
I remember being invited by IBM to some sort of lunch junket with Grady Booch (IBM had acquired Rational Software). The guy basically spouted the most inane platitudes it has ever been my misfortune to be on the receiving end of, despite my working for a company so large it had not just architects but also IT Urbanists.
I'll tell you what though, if you have a programming task that you find boring, over-engineering it and over-architecting it can make it _so_ much more enjoyable.
You better have the self-delusive ability to love and cherish that over-engineered system, because you will go from "not enough to do" to "can't keep up with the business because every little change requires 40 hours of heads-down work" in no time flat.
This is a good one. Joel Spolsky's writing has been a huge influence on me over the past 20 years. For anyone who liked this article but may not be familiar with his other writings: I encourage you to look at his "reading lists" (posted on https://www.joelonsoftware.com/) for some more gems.
What is dubbed as an "architecture astronaut" is, in my opinion, a researcher in software engineering as is the work they do. Largely, software engineering and practices aren't well defined and there's a lot of ways to approach a problem. We haven't found best approaches but in many cases we've slowly began converging on some architectural approaches for applications. These are really frameworks to think of how to approach a specific type of software system, much in the way research provides foundational theory to think of work in its domain.
We don't think of it that way, but I personally believe that's really what it is. It's a reductionist (abstracted) approach of developing a framework around a set of observations. Just like research, it may be too far abstracted to be relevant to the problem at hand and may take years before it becomes useful. That's just my perspective, though.
A good researcher should be an empiricist. They might want to test whether a pet theory applies to a new domain, but they should be challenging that assumption and open to the possibility that it doesn't. The architects who cause problems are those who dogmatically insist on a particular approach in defiance of all evidence.
I think that's a reasonable way of framing it I guess, but the reality is the industry on the whole doesn't have a place to put people like this. Most companies don't have a need for that kind of research. They just have to ship something.
Nor is it the case that everyone who does this kind of "research" is actually qualified to be doing it.
“ Another common thing Architecture Astronauts like to do is invent some new architecture and claim it solves something. Java, XML, Soap, XmlRpc, Hailstorm, .NET, Jini, oh lord I can’t keep up. And that’s just in the last 12 months!”
Wow, this hasn’t aged well. I always found Joel’s articles to be interesting but pretty limited in actual wisdom. He writes as if to be making profound observations, but in reality they are actually pretty narrow minded and really only apply to a very narrow nitch of computing as a whole and really only apply well to a certain startup type — not technically complex communications, productivity or organizational type software.
His advice is invalid for the development of anything more complex, for example you shouldn’t take his advice if you’re building a biotech company or starting a new kind of tech company that isn’t your run of the mill CRUD app.
I think it’s rather disingenuous and quite arrogant to make generalizations about the types of people who work at big companies (without even knowing what they do or having ever met them). I’m sure the same traits that make one have disdain for corporations are the same drivers that cause one to become an entrepreneur, and then blog loudly about it to the world.
So... I think a lot this is two problems, not one.
One is definitely climbing the transaction ladder to the point of no oxygen, Astronaut Architecture. But, I don't think that alone explains the amount of bombastic, heroic, utopian, grandiloquence of those Astronaut Architecture quotes.
People describing their jobs, their companies, ideas and such seem draw to grandiose & abstract nonsense. "Solutions-talk." Walk around a lot of business-ey trade shows and read plaques. 90% of the time, it is impossible to know what they do, who they do it for, why. They all do "business, people, and technology solutions." Even if you stop with questions, the first answer is always hopelessly abstract. It takes a lot of digging to eventually find out they do custom spreadsheets for dentists.
Meaningful statements are limiting. Who wants to limit themselves?
Also, it works. Saying something specific enough to be meaningful opens you to criticism, being eliminated by process of elimination, etc.
Architecture Astronautary feeds comfortably into sales, marketing, investor relations, recruitment. It's acceptable in boardrooms, AGMs, job descriptions. Media is happy to report on it.
"...and by 'we', of course, I mean a team of developers larger than our entire engineering division, dedicated to developing and maintaining xyz. Why do you ask?"
It's not like the architects at Facebook would do something like scrap Android's gradle build system and replace it with their own custom build system...oh yaa, they did do that.
> If Napster wasn’t peer-to-peer but it did let you type the name of a song and then listen to it, it would have been just as popular.
This is a very effective statement. Today p2p for music is certainly alive but has greatly been surpassed by services like YouTube and Spotify (and Rdio, sadly dead before it’s time). One is ad supported, the others paid. But they all just let the user search and listen.
Popcorn Time has done this for movies and tv. It’s purely p2p. Disliked by content owners, but they’ve largely failed to provide the same kind of universal search and watch functionality that the app provides. Hulu, Netflix, Apple+, Disney+, insert other streaming services. They all basically fail at usable search and recommendation usability and have limited overall content.
> They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don’t contribute to the bottom line.
Is is the really big company that makes you die inside or the people themselves?
I tend to think its the company... its soo hard for me to work and feel productive at a large company. Something just oozes nobody really cares about you or what your doing. Everyone is just trying to do the bare minimum and go home.
Premature optimisation is a real pain when it comes to software design and architecture. However, abstraction is a powerful and necessary tool that can make our life a lot easier by avoid repetition (DRY - don't repeat yourself).
A good architect worth their salt will be able to find the right balance. To distill and simplify a problem down to the absolute minimum where it cannot and should not be abstracted anymore before it lose or miss its core objectives and reason to exist.
Much of what Joel says here - especially the conclusion at the end - is also mirrored in what Steve Jobs said when confronted over shutting down OpenDoc: "You have to start with the customer experience and work backwards to the technology. You can't start with the technology and figure out where you're gonna sell it."
The peer to peer part definitely didn't age well. And the Java part too.
Nobody likes bombastic claims, but these likely go from marketing than from architects. It's important to see beyond the marketing and recognize the engineering thinking and potential behind technologies.
"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!”"
Strong blockchain vibes in this and the paragraph that follows it.
I think that example was interesting because he basically described BitTorrent (a more general Napster that's not just a push-button music player) as the potential brainchild of astronauts, but that actually was really useful to millions of people. So maybe the astronauts do have a point sometimes.
well, the tragedy now compared to 2001 when Joel wrote this, is the architecture astronauts are no longer limited to big corps. with vc money, early stage startups got money to boot.
I don't know how many early stage startups, I have encountered barely out of a seed stage with microservice this, serveless this, all running of course on k8's for unlimited scaling.
if frontend was madness then current trends in backend dev are madness ^2.
I have completely switched off now from node.js work to on saner boring things.
[+] [-] astronauthere|4 years ago|reply
One should give credit to Joel for correctly identifying the issue: great thinkers excel in abstract thought. Many of the comments here, however, seem to misunderstand his point about the propensity of creative minds to continue the refinement process and "not knowing when to stop". One (codeulike) apparently thinks simply being "bored" is what drives abstract thinkers. Let me assure you that is not the case, nor is it an inability to code. Many architecture astronauts started out as wiz coders.
Now let's review the gifts given by said astronauts - I'll limit to 2 examples but there are more:
- LISP is the mind product of a software astronaut.
- UNIX ("everything is a file") is the product of software space exploration.
My advice to serious young software engineers is to not accept mediocrity and imprecise thinking as acceptable standards for their chosen vocation. This cult of celebrating mediocrity in software design is a transient phase (20 years to date) and it is mostly a side effect of the introduction of facile soap boxes via the internet and blog sphere. When the dust settles, deep thinking and an ability to conceive powerful abstractions will yet again take center stage.
Software, after all, is all about abstraction.
[+] [-] rwallace|4 years ago|reply
- If your goal is to create great new architecture, that's fine, go for it.
- But if your goal is to ship a product to customers, on a tight schedule – say, you are a startup trying to get an MVP out the door before the end of your runway – then you should probably not be doing more than a fairly minimal amount of architecture, and you should beware of the temptation to do so.
Note that both your examples were created by people employed by large, wealthy organizations (MIT and AT&T respectively) that could afford to give them plenty of time to explore interesting new ideas. That's a great situation to be in, the world would be a better place if we put more people in that situation, and if you are in it, then you should take advantage of it. But if you are unfortunately not in it, then you should be aware of that fact.
[+] [-] oroul|4 years ago|reply
[+] [-] goto11|4 years ago|reply
But you may have a point with "everything is a file", and I wouldn't say that pattern have been entirely successful outside of actual files. I'm inherently skeptical towards any "everything is a..." philosophies. They tend to look good on paper but become ugly when they hit the gnarly real world.
[+] [-] smcl|4 years ago|reply
This is a pretty huge leap from what the commenter actually said, which was:
> I'll tell you what though, if you have a programming task that you find boring, over-engineering it and over-architecting it can make it _so_ much more enjoyable.
It seems you've misinterpreted many of the comments. People aren't upset about any kind of architectural design, only where it crosses a hard-to-define threshold into "over-architected". This is pretty hard to quantify exactly, but it is entirely likely you, codeulike and the rest would have an identical threshold where you'd say "you've gone too far ..." on some design.
[+] [-] cjfd|4 years ago|reply
[+] [-] throwaway423342|4 years ago|reply
> My advice to serious young software engineers is to not accept ''m and imprecise thinking as acceptable standards for their chosen vocation. Hmm? What straw man are you attacking?
[+] [-] epiphanitus|4 years ago|reply
So I guess the question is - what's the best way to scope and evangelize a 'moonshot' project? Or should you just shut your trap and go join a startup?
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] raverbashing|4 years ago|reply
Instead we have ended up with an overly bureaucratic format and process that is mostly used for paper-pushing and vendor lock-in pretty much.
[+] [-] reilly3000|4 years ago|reply
[+] [-] codeulike|4 years ago|reply
.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.
[+] [-] Jensson|4 years ago|reply
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.
[+] [-] hsn915|4 years ago|reply
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.
[+] [-] aazaa|4 years ago|reply
What happens if you don't go far enough up, abstraction wise?
You end up repeating yourself - everywhere. You end up with globals everywhere. You end up with God Classes. You end up with epic-length functions nested 15 levels deep. You end up with primitives trying to do the job that well-crafted data structures, named using the terminology of the problem domain, should be doing.
It's odd that the author rails against "astronauts" without addressing the very real motivations that lead to good architectures. Like all design, there are tensions in software development, and navigating the forces pulling you in opposite directions regarding architecture is one of the most important contribution you can make.
It's also odd that the author never calls out specific architectures that are the work of astronauts, just "the stupendous amount of millennial hype that surrounds them." He seems to hint in the introduction that CORBA is (was) one of them, but even that reference is pretty vague.
[+] [-] JimDabell|4 years ago|reply
When the architecture is underdeveloped, it only takes somebody with a little more experience to fix the problem using incremental refactoring. But when astronauts have run wild with too many abstractions, it can be incredibly difficult to unravel them, especially if you don’t have the original developers’ help.
[+] [-] 0xFACEFEED|4 years ago|reply
Joel's criticism targets PEOPLE not IDEAS. See the blog post title. There's nothing wrong with abstractions as an idea. The issue is when folks apply them in inappropriate and unnecessary ways.
When a smart, motivated, and caring person programs a computer then sensible abstractions will naturally emerge. A complex proprietary formula will not be copy-pasted because of course that's a bad idea. These judgement calls are important!
Globals are not always bad. Some data is truly global and should not be instanced, so to speak.
God classes are not always bad. Sometimes it's important to isolate experimental behavior from everything else and get it done quickly. Throw it into a class, throw the class into a file, mash a bunch of code in there, and test it out. If it works out then refactor it.
Primitives are not always bad. Data structures are not zero cost! The amount of times I've seen a "well crafted" (???) data structure tank performance by orders of magnitude is just sad.
> It's odd that the author rails against "astronauts" without addressing the very real motivations that lead to good architectures. Like all design, there are tensions in software development, and navigating the forces pulling you in opposite directions regarding architecture is one of the most important contribution you can make.
This paragraph is over-engineered.
[+] [-] SnorkelTan|4 years ago|reply
[+] [-] TeeMassive|4 years ago|reply
Or you end up with a flat hierarchy of isolated modules that can do one thing and one thing only but can do it well.
Architectures are what can't be changed easily and it is easier to change what is small. Architectures that try hard to accommodate every case always end up getting in the way of everything.
[+] [-] IncRnd|4 years ago|reply
I've found more usefulness in being pithy than in being prolix.
[+] [-] smoldesu|4 years ago|reply
[+] [-] fmajid|4 years ago|reply
[+] [-] codeulike|4 years ago|reply
I'll tell you what though, if you have a programming task that you find boring, over-engineering it and over-architecting it can make it _so_ much more enjoyable.
[+] [-] dkarl|4 years ago|reply
[+] [-] cmrdporcupine|4 years ago|reply
[+] [-] paxys|4 years ago|reply
[+] [-] systemvoltage|4 years ago|reply
[+] [-] bigbizisverywyz|4 years ago|reply
[+] [-] daveslash|4 years ago|reply
[+] [-] Frost1x|4 years ago|reply
We don't think of it that way, but I personally believe that's really what it is. It's a reductionist (abstracted) approach of developing a framework around a set of observations. Just like research, it may be too far abstracted to be relevant to the problem at hand and may take years before it becomes useful. That's just my perspective, though.
[+] [-] lmm|4 years ago|reply
[+] [-] cmrdporcupine|4 years ago|reply
Nor is it the case that everyone who does this kind of "research" is actually qualified to be doing it.
[+] [-] chrisseaton|4 years ago|reply
So they're publishing papers with falsifiable hypotheses and subjecting themselves to peer review, right?
No? Oh.
[+] [-] iamleppert|4 years ago|reply
Wow, this hasn’t aged well. I always found Joel’s articles to be interesting but pretty limited in actual wisdom. He writes as if to be making profound observations, but in reality they are actually pretty narrow minded and really only apply to a very narrow nitch of computing as a whole and really only apply well to a certain startup type — not technically complex communications, productivity or organizational type software.
His advice is invalid for the development of anything more complex, for example you shouldn’t take his advice if you’re building a biotech company or starting a new kind of tech company that isn’t your run of the mill CRUD app.
I think it’s rather disingenuous and quite arrogant to make generalizations about the types of people who work at big companies (without even knowing what they do or having ever met them). I’m sure the same traits that make one have disdain for corporations are the same drivers that cause one to become an entrepreneur, and then blog loudly about it to the world.
[+] [-] dalbasal|4 years ago|reply
One is definitely climbing the transaction ladder to the point of no oxygen, Astronaut Architecture. But, I don't think that alone explains the amount of bombastic, heroic, utopian, grandiloquence of those Astronaut Architecture quotes.
People describing their jobs, their companies, ideas and such seem draw to grandiose & abstract nonsense. "Solutions-talk." Walk around a lot of business-ey trade shows and read plaques. 90% of the time, it is impossible to know what they do, who they do it for, why. They all do "business, people, and technology solutions." Even if you stop with questions, the first answer is always hopelessly abstract. It takes a lot of digging to eventually find out they do custom spreadsheets for dentists.
Meaningful statements are limiting. Who wants to limit themselves?
Also, it works. Saying something specific enough to be meaningful opens you to criticism, being eliminated by process of elimination, etc.
Architecture Astronautary feeds comfortably into sales, marketing, investor relations, recruitment. It's acceptable in boardrooms, AGMs, job descriptions. Media is happy to report on it.
Obscurity by abstraction works.
[+] [-] mhh__|4 years ago|reply
[+] [-] yongjik|4 years ago|reply
[+] [-] Mc91|4 years ago|reply
[+] [-] geuis|4 years ago|reply
This is a very effective statement. Today p2p for music is certainly alive but has greatly been surpassed by services like YouTube and Spotify (and Rdio, sadly dead before it’s time). One is ad supported, the others paid. But they all just let the user search and listen.
Popcorn Time has done this for movies and tv. It’s purely p2p. Disliked by content owners, but they’ve largely failed to provide the same kind of universal search and watch functionality that the app provides. Hulu, Netflix, Apple+, Disney+, insert other streaming services. They all basically fail at usable search and recommendation usability and have limited overall content.
[+] [-] dnndev|4 years ago|reply
Is is the really big company that makes you die inside or the people themselves?
I tend to think its the company... its soo hard for me to work and feel productive at a large company. Something just oozes nobody really cares about you or what your doing. Everyone is just trying to do the bare minimum and go home.
[+] [-] BishoyDemian|4 years ago|reply
A good architect worth their salt will be able to find the right balance. To distill and simplify a problem down to the absolute minimum where it cannot and should not be abstracted anymore before it lose or miss its core objectives and reason to exist.
[+] [-] shockeychap|4 years ago|reply
https://youtu.be/oeqPrUmVz-o?t=110
[+] [-] oytis|4 years ago|reply
Nobody likes bombastic claims, but these likely go from marketing than from architects. It's important to see beyond the marketing and recognize the engineering thinking and potential behind technologies.
[+] [-] backtoyoujim|4 years ago|reply
[+] [-] clpm4j|4 years ago|reply
Strong blockchain vibes in this and the paragraph that follows it.
[+] [-] ziftface|4 years ago|reply
[+] [-] dzonga|4 years ago|reply
[+] [-] FpUser|4 years ago|reply
[+] [-] keithwhor|4 years ago|reply