4 ms·

"When great thinkers ..." One should give credit to Joel for correctly identifying the issue: great thinkers excel in abstract thought. Many of the comments he

"When great thinkers ..." 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.

deleted 5y ago
[deleted]
oroul 5y ago
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.
- thewakalix 5y ago
  "Everything is a file" seems comparable to "everything is a message".
  - chii 5y ago
    The difference between a file and a message is that a file does not prescribe format of the file - it's usually application dependent, but is understood to be plain text. A "message" tends to have formats associated with it (which is what differentiate it from being just a "file" that's transferred via a protocol). These formats, like JSON, or xml, or whatever new fangled formats kids these days use, now requires architectural astronauting; namely, common field names, or standards, so that different programs would parse them similarly. And now you'd want schemas for those formats, and automatic parser generated for those formats, and more and more...
    - adwn 5y ago
      > but is understood to be plain text It's not. Plenty of Unix tools work with binary files. > A "message" tends to have formats associated with it It doesn't. At least, not any more than a "file" tends to have formats associated with it.
  - tuyiown 5y ago
    It's the thing with abstractions: changing angle changes the abstraction by seemingly replacement candidates, but only the good ones maps properly onto physical hardware and human cognition. eg: "everything is a file" maps properly to both physical storage with addressable, streamable content and to the human mind as data reachable by classification (file name). Maybe a revolutionary OS design could better that with "everything is a message", but I think you can understand why one can have doubt on this translation from files.
- stkdump 5y ago
  Simplicity does not contradict architecture. For some (me included), it is even the essence of it. Leave out the bells and whistles. This is why JSON is so successful, even though we had XML long ago. Technology should be more of that, and I would consider it superior architecture.
- galaxyLogic 5y ago
  I would say Unix is a system designed to be simple and powerful. It takes a lot of thinking to achieve a system which is both simple AND powerful. Whereas things like XML and Multics are powerful they can do everything but they are not simple. In the end that limits their power because they are hard to learn and things built with them are difficult to understand, because they are not simple. And when something is hard to understand it is also error-prone, and such a system is fragile. It takes "astronauts" who think hard about the architecture to come up with systems that are simple and powerful at the same time.
  - bryanrasmussen 5y ago
    >Whereas things like XML and Multics are powerful they can do everything but they are not simple. the original XML Spec is pretty simple https://www.w3.org/TR/xml/ https://www.w3.org/TR/xml/ even if you add in namespaces - still simple https://www.w3.org/TR/xml-names/ https://www.w3.org/TR/xml-names/ The difficulty in XML really came with XML Schemas and the need to wind that in every subsequent spec.
- emodendroket 5y ago
  There is the whole worse is better thing too
- richardw 5y ago
  “It was designed” - that’s the key. We all know how hard it is to make things simple. That doesn’t come naturally. Hardest stuff I’ve ever done is to go through complexity to reach what is simple. (Definitely paraphrasing someone else there.) Right now I have a project of potentially infinite complexity and we need to build really fast. A lot of my focus has been finding the very few pieces of bedrock and fixing on those, allowing the rest to vary as our appetite for complexity grows. Start today with an achievable goal, test hypotheses, don’t paint ourselves into a corner. All team comments are how simple it is. That’s by...design.
throwaway423342 5y ago
> 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?
cjfd 5y ago
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.
rwallace 5y ago
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.
raverbashing 5y ago
Well but XML was supposed to be the abstraction to rule them all. 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.
- Kuraj 5y ago
  Can you explain the vendor lock-in bit with regards to XML?
  - raverbashing 5y ago
    Vendor/group controlled XML standards. See the standards for EHRs for example: https://www.healthit.gov/isa/sites/isa/files/inline-files/2019ISAReferenceEdition.pdf https://www.healthit.gov/isa/sites/isa/files/inline-files/20...
smcl 5y ago
> 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.
goto11 5y ago
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.
- loopz 5y ago
  Linux seems pretty powerful and successful though, and it's built on "everything is a file" as a foundation.
epiphanitus 5y ago
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?

deleted 5y ago

[deleted]

oroul 5y ago

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.

thewakalix 5y ago
"Everything is a file" seems comparable to "everything is a message".
- chii 5y ago
  The difference between a file and a message is that a file does not prescribe format of the file - it's usually application dependent, but is understood to be plain text. A "message" tends to have formats associated with it (which is what differentiate it from being just a "file" that's transferred via a protocol). These formats, like JSON, or xml, or whatever new fangled formats kids these days use, now requires architectural astronauting; namely, common field names, or standards, so that different programs would parse them similarly. And now you'd want schemas for those formats, and automatic parser generated for those formats, and more and more...
  - adwn 5y ago
    > but is understood to be plain text It's not. Plenty of Unix tools work with binary files. > A "message" tends to have formats associated with it It doesn't. At least, not any more than a "file" tends to have formats associated with it.
- tuyiown 5y ago
  It's the thing with abstractions: changing angle changes the abstraction by seemingly replacement candidates, but only the good ones maps properly onto physical hardware and human cognition. eg: "everything is a file" maps properly to both physical storage with addressable, streamable content and to the human mind as data reachable by classification (file name). Maybe a revolutionary OS design could better that with "everything is a message", but I think you can understand why one can have doubt on this translation from files.
stkdump 5y ago
Simplicity does not contradict architecture. For some (me included), it is even the essence of it. Leave out the bells and whistles. This is why JSON is so successful, even though we had XML long ago. Technology should be more of that, and I would consider it superior architecture.
galaxyLogic 5y ago
I would say Unix is a system designed to be simple and powerful. It takes a lot of thinking to achieve a system which is both simple AND powerful. Whereas things like XML and Multics are powerful they can do everything but they are not simple. In the end that limits their power because they are hard to learn and things built with them are difficult to understand, because they are not simple. And when something is hard to understand it is also error-prone, and such a system is fragile. It takes "astronauts" who think hard about the architecture to come up with systems that are simple and powerful at the same time.
- bryanrasmussen 5y ago
  >Whereas things like XML and Multics are powerful they can do everything but they are not simple. the original XML Spec is pretty simple https://www.w3.org/TR/xml/ https://www.w3.org/TR/xml/ even if you add in namespaces - still simple https://www.w3.org/TR/xml-names/ https://www.w3.org/TR/xml-names/ The difficulty in XML really came with XML Schemas and the need to wind that in every subsequent spec.
emodendroket 5y ago
There is the whole worse is better thing too
richardw 5y ago
“It was designed” - that’s the key. We all know how hard it is to make things simple. That doesn’t come naturally. Hardest stuff I’ve ever done is to go through complexity to reach what is simple. (Definitely paraphrasing someone else there.) Right now I have a project of potentially infinite complexity and we need to build really fast. A lot of my focus has been finding the very few pieces of bedrock and fixing on those, allowing the rest to vary as our appetite for complexity grows. Start today with an achievable goal, test hypotheses, don’t paint ourselves into a corner. All team comments are how simple it is. That’s by...design.

throwaway423342 5y ago

> 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?

cjfd 5y ago

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.

rwallace 5y ago

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.

raverbashing 5y ago

Well but XML was supposed to be the abstraction to rule them all. 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.

Kuraj 5y ago
Can you explain the vendor lock-in bit with regards to XML?
- raverbashing 5y ago
  Vendor/group controlled XML standards. See the standards for EHRs for example: https://www.healthit.gov/isa/sites/isa/files/inline-files/2019ISAReferenceEdition.pdf https://www.healthit.gov/isa/sites/isa/files/inline-files/20...

smcl 5y ago

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

goto11 5y ago

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.

loopz 5y ago
Linux seems pretty powerful and successful though, and it's built on "everything is a file" as a foundation.

epiphanitus 5y ago

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?