6 ms·

As soon as I finished reading the article, the very first thing that came in my mind is Dieter Rams' "10 Principles of Good Design"; I have been following his p

As soon as I finished reading the article, the very first thing that came in my mind is Dieter Rams' "10 Principles of Good Design"; I have been following his principles as much as I can, as they match, more or less, those of UNIX's philosophy: 1. Good design is innovative 2. Good design makes a product useful 3. Good design is aesthetic 4. Good design makes a product understandable 5. Good design is unobtrusive 6. Good design is honest 7. Good design is long-lasting 8. Good design is thorough down to the last detail 9. Good design is environmentally-friendly 10. Good design is as little design as possible

avidiax 2y ago
These don't sound like the UNIX philosophy. My impression is that UNIX is more like what's outlined here: https://web.stanford.edu/class/archive/cs/cs240/cs240.1236/old//sp2014/readings/worse-is-better.html https://web.stanford.edu/class/archive/cs/cs240/cs240.1236/o...
- MonkeyClub 2y ago
  It's informally semi-codified: https://en.m.wikipedia.org/wiki/Unix_philosophy https://en.m.wikipedia.org/wiki/Unix_philosophy
  - pjmlp 2y ago
    A philosophy that gets worship like some cult, and yet most UNIX systems hardly follow up, or most tools when checking those endless man pages full of options.
  - mike_hearn 2y ago
    It's primarily just a statement of widely agreed principles everyone has always claimed to follow, even when UNIX was new, and others arguably followed them with more success e.g. > The Unix philosophy emphasizes building simple, compact, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators Nobody says "we want to build complicated, sprawling, unclear, unmodular and rigid code", so this isn't a statement that sets UNIX apart from any other design. And if we look at the competing space of non-UNIX platforms, we see that others arguably had more success implementing these principles in practice. Microsoft did COM, which is a much more aggressive approach to modularity and composable componentization than UNIX. Apple/NeXT did Objective-C and XPC, which is somewhat similar. Java did portable, documented libraries with extensibility points better than almost any other platform. Many of the most famous principles written down in 1978 didn't work and UNIX practitioners now do the exact opposite, like: • "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features" yet the --help for GNU grep is 74 lines long and documents 49 different flags. • "Don't hesitate to throw away the clumsy parts and rebuild them." yet the last time a clumsy part of UNIX was thrown away and rebuilt was systemd, yielding outrage from people claiming to defend the UNIX philosophy. About the only part of the UNIX philosophy that's actually unique and influential is "Write programs to handle text streams, because that is a universal interface". Yet even this principle is a shadow of its former self. Data is exchanged as JSON but immediately converted to/from objects, not processed as text in and of itself. Google, one of the world's most successful tech companies, bases its entire infrastructure around programs exchanging and storing binary protocol buffers. HTTP abandoned text streams in favor of binary. Overall the UNIX philosophy has little to stand apart other than a principled rejection of typed interfaces between programs, an idea that has few defenders today.
- unscaled 2y ago
  And the "Worse is Better" follows some good design principles, but in a very twisted way: the program is designed to minimize the effort the programmer needs to write it. Implementation simplicity meant one important thing: Unix could be quickly developed and iterated. When Unix was still new, this was a boon and Unix grew rapidly, but at one point backward compatibility had to be maintained and we remained with a lot of cruft. Unfortunately, since implementation simplicity and development speed nearly always took precedence over everything else, this cruft could be quite painful. If you look at the C standard library and traditional Unix tools, they are generally quite user hostile. The simple tools like "cat" and "wc" are simple enough to make them useful, but most of the tools have severe shortcomings, either in the interface, lack of critical features or their entire design. For example: 1. ls was never really designed to output directory data in a way that can be parsed by other programs. It is so bad that "Don't parse ls" became a famous warning for shell script writers[1]. 2. find has a very weird expression language that is hard to use or remember. It also never really heard about the "do one thing well" part of Unix philosophy and decided that "be mediocre at multiple things" is a better approach. Of course, finding files with complex queries and executing complex actions as a result is not an easy task. But find makes even the simplest things harder than they should be. A good counterexample is "fd"[2]. You want to find that has a "foo" somewhere in its name in the current directory and display the path in a friendly manner? fd foo vs find . -name 'foo' -Printf "%P\n". What to find all .py files and run "wc -l" on each of them? fd --extension py --exec wc -l (or "fd -e py -x wc -l" if you like it short). "Find requires you to write find . -name '*.py' -exec wc -l {} ;". I keep forgetting that and have to search the manual every time. Oh, and as a bonus, if you forget to quote your wildcards for find they may (or may not!) be expanded by the shell, and end up giving you completely unexpected results. Great foolproof design. 3. sed is yet another utility which is just too hard to learn. Most people use it as mostly as a regex find-and-replace tool in pipes nowadays, but its regex syntax is quite lacking. This is not entirely sed's fault, since it predates Perl and PCRE which set the modern standard for regular expressions that we expect to more or less work the same everywhere. But it is another example of a tool that badly violates the principles of good design. The Unix Haters Handbook is full of many more examples, but the reality is that Unix won because other OSes could not deliver what their users needed fast enough. Unix even brought some good ideas to the mass market (like pipes) even if the implementation was messy. We now live under the shadow of its legacy, for better or worse. But I don't think we should idolize the Unix philosophy. It is mostly a set of principles ("everything is a file", "everything is text" and "each tool should do one job", "write programs to work together") that was never strictly followed (many things in UNIX are not files, many commands do multiple jobs, most commands don't interact nicely with each other unless you just care about opaque lines). But most importantly, the Unix philosophy doesn't extend much beyond designing composable command line tools that handle line-oriented text for power users. [1] https://mywiki.wooledge.org/ParsingLs https://mywiki.wooledge.org/ParsingLs [2] https://github.com/sharkdp/fd https://github.com/sharkdp/fd
scarface_74 2y ago
And most of that misses the goal of why you write software for a business. You write software for a company so someone will give them money for it or so the company can save money Everything else takes a backseat to that core mission. The first goal when writing software is to efficiently get to a point where one of those goals can be met. It makes no sense to polish software if you are going to run out of money before it gets released, management cuts funding or you can’t find product market fit to convince investors to give you money depending on what your goal is. Code doesn’t always need to be long lasting, you can’t predict how the market will change, how the underlying platform will change, when a better funded competitor will come in and eat your lunch, etc. Good design doesn’t need to be “innovative”. It needs to fit within the norms of the platform or ecosystem it is part of.
- Doches 2y ago
  Good thing not all of us write software for a business. I write little utilities for my parents, games for my son, a web shop for my wife. I write social spaces for myself and my friends. I write tools for myself. I write software for strangers on the internet. I write software when I’m drunk, to test myself. Sometimes I write software simply for the joy of writing it, and it never runs again after that first “ah, finally!” moment. Aah, time well spent. Equating “writing software” with “fulfilling business goals” is…quite depressing. Get outside! Feel the sunshine on your face! Write your own image-processing DSL, just for the sheer unbridled hell of it! Learn Nim! Why not? (Ok, maybe skip the last one)
  - scarface_74 2y ago
    You realize “writing code on a computer” is just the opposite of “getting outside”? Getting outside for me is getting outside. My wife is out of town this weekend at a conference. I woke up, fixed breakfast, went outside and swam a few laps in the pool enjoying this 80 degree weather (the joys of living in Florida), hung out at the bar downstairs, came back upstairs and took a shower and I am heading back downstairs to hang out at one of the other bars downstairs and just shoot the shit with the bartender who is a friend of mine and whoever else shows up while drinking soda (I go down to hang out not always to drink) and listening to bad kaorake. When my wife comes back tomorrow, we will hang out during the day and go back downstairs to the bar tomorrow to watch the Super Bowl. We have 8 vacations planned this year not including 5-6 trips to fly up to our home town in Atlanta (where we lived all of our adult lives until two years ago) for things going on in our friends lives and to fly to my child hood home to see my parents and family. Not bragging, most of our vacations aren’t anything exotic or expensive and I play the credit card point/sign up bonus/churnimg game to offset some of the costs. My focuses on how to add business value was what allowed me to find strategic consulting jobs where most jobs are still fully remote.
musicale 2y ago
> they match, more or less, those of UNIX's philosophy 1. Good design is innovative UNIX innovated by simplifying Multics - throwing away ring security and PL/I's memory safety features. Linux innovated by cloning UNIX, giving it away for free, and avoiding the lawsuit that sidelined BSD. 2. Good design makes a product useful Yet somehow people managed to use UNIX anyway. 3. Good design is aesthetic UNIX threw away clear, long-form command forms and kept short, cryptic abbreviations like "cat" (short for "felis cattus") and "wc" (short for "toilet"). Its C library helpfully abbreviates "create" as "creat", because vowels are expensive. 4. Good design makes a product understandable See #3 5. Good design is unobtrusive That's why UNIX/Linux enthusiasts spend so much time configuring their systems rather than using them. 6. Good design is honest The UNIX name indicates it is missing something present in Multics. Similarly, "Linux" is the gender-neutralized form of "Linus". 7. Good design is long-lasting Like many stubborn diseases, UNIX has proven hard to eradicate. 8. Good design is thorough down to the last detail UNIX/Linux enthusiasts love using those details to try to figure out how to get Wi-Fi, Bluetooth, and GPU support partially working on their laptops. 9. Good design is environmentally-friendly Linux recycles most of UNIX's bad ideas, and many of its users/apologists. 10. Good design is as little design as possible Linux beats UNIX because it wasn't designed at all.
- grose 2y ago
  Reads like it came straight out of the UNIX-HATERS Handbook, nice. (For those unfamiliar: https://web.mit.edu/~simsong/www/ugh.pdf https://web.mit.edu/~simsong/www/ugh.pdf)
  - pjmlp 2y ago
    UNIX haters handbook exists, because many of us don't worship at the fate of UNIX church. Yes, it did some things right, but also did plenty of them bad, lets not worship it as the epitome of OS design, cloning it all the time without critical thinking. Alone the fact that its creators went on to design Plan 9, Inferno, Alef, Limbo and Go, shows even they moved on to better approaches.
gyomu 2y ago
Rams’ principles were perhaps noteworthy when he first vocalized them as the state of design discourse was much more primitive back then (not even sure of that actually), but today they ring quite simplistic and hollow, and kind of useless as actual decision making tools. “Good design is as little design as possible” ok cool but I have 30 different feature requests coming in every week from actual users, that doesn’t really help me make concrete design decisions “Good design is aesthetic” whose aesthetic? Aesthetic is extremely cultural and arbitrary, my designers are fighting over whether a photorealistic leather texture is more aesthetic than a gradient texture background, how does that help? “Good design makes a product useful” uh yeah okay I’ve never had a design problem that was solved by someone saying “you know what, we should just make this product useful” “oooh right how did we not think of that”. I mean these principles all sound good and high falutin’ as abstract statements, but I’ve never found them useful or actionable in my 15+ years working as a designer.
- skydhash 2y ago
  My takes: “Good design is as little design as possible” What you create should be a natural flow of what your clients needs to do. Don't go and add lot of options like a plane cockpit. Which usually means try to find the common theme and adding on top, and also clamping down on fantasy wishes "Good design is aesthetic" I'd take the definition of pleasing instead of beautiful for the term. When learning to draw, an often given advice is just to focus and detail only a single part of the whole picture, everything else can be left out. So discussion over a single thing is usually meaningless. If it's not going to be the focus point of interaction, as long as it meshes into the whole, no one care about the exact details. “Good design makes a product useful” Usability is a whole field, and you can find the whole corpus under the HCI (Human Computer Interaction) keyword. Focus on meeting this baseline, then add your creativity on top. > I mean these principles all sound good and high falutin’ as abstract statements, but I’ve never found them useful or actionable It's kinda like Philosophy, you have to understand what it means for yourself. It's not a cake recipe to follow, but more of a framework from where to derive you own methodology.
  - lloeki 2y ago
epolanski 2y ago
> Good design is innovative Why? Maybe it's meant in an artistic sense, but under an engineering one I just don't see it.
- scarface_74 2y ago
  Artistic design leads you to the unnecessary skeuomorphism of iOS 1-6
  - gamedever 2y ago
    that was vastly better than today's "guess which things are interactive" design where what's clickable/editable/interactable is just a guessing game.
    - wwweston 2y ago
      This. Stuff like stitched leather was obviously indulgent without a lot of function, but skeumorphic buttons at least carried a standard complement of affordances that too much flat design ignores.
- idle_zealot 2y ago
  If it's not innovative, then you're reinventing the wheel and would be better off using someone else's good design.
  - cgh 2y ago
    From the article: "We are destroying software telling new programmers: “Don’t reinvent the wheel!”. But, reinventing the wheel is how you learn how things work, and is the first step to make new, different wheels."
    - idle_zealot 2y ago
      Reinventing the wheel is a great learning exercise, but it doesn't yeild great software.
0x1ceb00da 2y ago
> Good design is honest > Everything is a file
- hannasm 2y ago
  Is your interpretation that these two statements are at odds? What even is the intended meaning of "a file"? To me it could be: Something accessible via a file descriptor that can be read from and/or written to. Feel free to add some other details like permissions, as needed. Perhaps they should allow for folders as well, since a complex piece of hardware undoubtedly needs to expose multiple files to be robust, but the underlying intention was to create a standardized way of interacting with hardware. Sectors on disk, switches, analog devices like a speaker, i2c and other hardware ideas all need to be read from or written to in some form to be useful
  - otabdeveloper4 2y ago
    Take a simple and obvious example - say, controlling a musical instrument from a computer via MIDI. Calling that a "file" is ... a humongous stretch, to put it mildly.
  - tsimionescu 2y ago
    I think they meant that in any widely used Unix system today, there are a loooot of things which are not files, so the design is not honest. The most common example of soemthing almost all programs interact with universally is BSD sockets. In Plan9, which goes out of its way to follow this everything is a file philosophy, TCP/UDP connections are actually represented as files. You open a file and write something to it to create the connection, and then you read or write to other files to read the streams, and you write again to the control file to close the connection. On the server side, you similarly write to a control file to start accepting packets, and monitor a directory to check for new connections, and so on. Note that "file" here has a pretty clear definition: anything that can be interacted with using strictly the C FILE api - open()/read()/write()/close().
- pinoy420 2y ago
  > Good design is aesthetic > Xorg I guess it didn’t say pleasing?
frontalier 2y ago
why is it 10? why not 7 or 15?
MadWombat 2y ago
It seems to be one of those "pick any two" jokes, but those usually only have three items on the list. And yet pretty much everything on this list feels mutually exclusive.
- hobs 2y ago
  Everything had tradeoffs, but let's just list out things you called mutually exclusive: innovative vs useful, understandable vs honest, long lasting vs thorough, aesthetic vs unobtrusive, What?
khana 2y ago
[dead]
begueradj 2y ago
What is "good design" ? That's the question.
rapnie 2y ago
Based on UNIX philosophy too is Dan North's idea of Joyful Coding that does away with formal SOLID principles in favor of CUPID more playful ones: https://cupid.dev https://cupid.dev
blueflow 2y ago
The rules are too generic to be useful, because mankind still can't agree on what is "innovative", "useful", "aesthetic", ... and what isn't. Only rule 7. and 9. are measurable and not purely subjective.
- makeitdouble 2y ago
  And then rule 7. is debatable. If you design for an ephemeral state, it doesn't make sense to be long lasting. 3D printing a door handle that perfectly fits my hand, my door, the space it moves in and only lasts until I move to another house can be the ultimate perfect design _for me_. I'd see the same for prosthetic limbs that could evolve as the wearer evolves (e.g. growth up or ages) or what they expect from it changes.
lloeki 2y ago
This page has the 10 principles, along with a small text and a visual illustration for each one. https://www.vitsoe.com/us/about/good-design#good-design-is-innovative https://www.vitsoe.com/us/about/good-design#good-design-is-i...

avidiax 2y ago

These don't sound like the UNIX philosophy. My impression is that UNIX is more like what's outlined here: https://web.stanford.edu/class/archive/cs/cs240/cs240.1236/old//sp2014/readings/worse-is-better.html https://web.stanford.edu/class/archive/cs/cs240/cs240.1236/o...

MonkeyClub 2y ago
It's informally semi-codified: https://en.m.wikipedia.org/wiki/Unix_philosophy https://en.m.wikipedia.org/wiki/Unix_philosophy
- pjmlp 2y ago
  A philosophy that gets worship like some cult, and yet most UNIX systems hardly follow up, or most tools when checking those endless man pages full of options.
- mike_hearn 2y ago
  It's primarily just a statement of widely agreed principles everyone has always claimed to follow, even when UNIX was new, and others arguably followed them with more success e.g. > The Unix philosophy emphasizes building simple, compact, clear, modular, and extensible code that can be easily maintained and repurposed by developers other than its creators Nobody says "we want to build complicated, sprawling, unclear, unmodular and rigid code", so this isn't a statement that sets UNIX apart from any other design. And if we look at the competing space of non-UNIX platforms, we see that others arguably had more success implementing these principles in practice. Microsoft did COM, which is a much more aggressive approach to modularity and composable componentization than UNIX. Apple/NeXT did Objective-C and XPC, which is somewhat similar. Java did portable, documented libraries with extensibility points better than almost any other platform. Many of the most famous principles written down in 1978 didn't work and UNIX practitioners now do the exact opposite, like: • "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features" yet the --help for GNU grep is 74 lines long and documents 49 different flags. • "Don't hesitate to throw away the clumsy parts and rebuild them." yet the last time a clumsy part of UNIX was thrown away and rebuilt was systemd, yielding outrage from people claiming to defend the UNIX philosophy. About the only part of the UNIX philosophy that's actually unique and influential is "Write programs to handle text streams, because that is a universal interface". Yet even this principle is a shadow of its former self. Data is exchanged as JSON but immediately converted to/from objects, not processed as text in and of itself. Google, one of the world's most successful tech companies, bases its entire infrastructure around programs exchanging and storing binary protocol buffers. HTTP abandoned text streams in favor of binary. Overall the UNIX philosophy has little to stand apart other than a principled rejection of typed interfaces between programs, an idea that has few defenders today.
unscaled 2y ago
And the "Worse is Better" follows some good design principles, but in a very twisted way: the program is designed to minimize the effort the programmer needs to write it. Implementation simplicity meant one important thing: Unix could be quickly developed and iterated. When Unix was still new, this was a boon and Unix grew rapidly, but at one point backward compatibility had to be maintained and we remained with a lot of cruft. Unfortunately, since implementation simplicity and development speed nearly always took precedence over everything else, this cruft could be quite painful. If you look at the C standard library and traditional Unix tools, they are generally quite user hostile. The simple tools like "cat" and "wc" are simple enough to make them useful, but most of the tools have severe shortcomings, either in the interface, lack of critical features or their entire design. For example: 1. ls was never really designed to output directory data in a way that can be parsed by other programs. It is so bad that "Don't parse ls" became a famous warning for shell script writers[1]. 2. find has a very weird expression language that is hard to use or remember. It also never really heard about the "do one thing well" part of Unix philosophy and decided that "be mediocre at multiple things" is a better approach. Of course, finding files with complex queries and executing complex actions as a result is not an easy task. But find makes even the simplest things harder than they should be. A good counterexample is "fd"[2]. You want to find that has a "foo" somewhere in its name in the current directory and display the path in a friendly manner? fd foo vs find . -name 'foo' -Printf "%P\n". What to find all .py files and run "wc -l" on each of them? fd --extension py --exec wc -l (or "fd -e py -x wc -l" if you like it short). "Find requires you to write find . -name '*.py' -exec wc -l {} ;". I keep forgetting that and have to search the manual every time. Oh, and as a bonus, if you forget to quote your wildcards for find they may (or may not!) be expanded by the shell, and end up giving you completely unexpected results. Great foolproof design. 3. sed is yet another utility which is just too hard to learn. Most people use it as mostly as a regex find-and-replace tool in pipes nowadays, but its regex syntax is quite lacking. This is not entirely sed's fault, since it predates Perl and PCRE which set the modern standard for regular expressions that we expect to more or less work the same everywhere. But it is another example of a tool that badly violates the principles of good design. The Unix Haters Handbook is full of many more examples, but the reality is that Unix won because other OSes could not deliver what their users needed fast enough. Unix even brought some good ideas to the mass market (like pipes) even if the implementation was messy. We now live under the shadow of its legacy, for better or worse. But I don't think we should idolize the Unix philosophy. It is mostly a set of principles ("everything is a file", "everything is text" and "each tool should do one job", "write programs to work together") that was never strictly followed (many things in UNIX are not files, many commands do multiple jobs, most commands don't interact nicely with each other unless you just care about opaque lines). But most importantly, the Unix philosophy doesn't extend much beyond designing composable command line tools that handle line-oriented text for power users. [1] https://mywiki.wooledge.org/ParsingLs https://mywiki.wooledge.org/ParsingLs [2] https://github.com/sharkdp/fd https://github.com/sharkdp/fd

scarface_74 2y ago

And most of that misses the goal of why you write software for a business. You write software for a company so someone will give them money for it or so the company can save money Everything else takes a backseat to that core mission. The first goal when writing software is to efficiently get to a point where one of those goals can be met. It makes no sense to polish software if you are going to run out of money before it gets released, management cuts funding or you can’t find product market fit to convince investors to give you money depending on what your goal is. Code doesn’t always need to be long lasting, you can’t predict how the market will change, how the underlying platform will change, when a better funded competitor will come in and eat your lunch, etc. Good design doesn’t need to be “innovative”. It needs to fit within the norms of the platform or ecosystem it is part of.

Doches 2y ago
Good thing not all of us write software for a business. I write little utilities for my parents, games for my son, a web shop for my wife. I write social spaces for myself and my friends. I write tools for myself. I write software for strangers on the internet. I write software when I’m drunk, to test myself. Sometimes I write software simply for the joy of writing it, and it never runs again after that first “ah, finally!” moment. Aah, time well spent. Equating “writing software” with “fulfilling business goals” is…quite depressing. Get outside! Feel the sunshine on your face! Write your own image-processing DSL, just for the sheer unbridled hell of it! Learn Nim! Why not? (Ok, maybe skip the last one)
- scarface_74 2y ago
  You realize “writing code on a computer” is just the opposite of “getting outside”? Getting outside for me is getting outside. My wife is out of town this weekend at a conference. I woke up, fixed breakfast, went outside and swam a few laps in the pool enjoying this 80 degree weather (the joys of living in Florida), hung out at the bar downstairs, came back upstairs and took a shower and I am heading back downstairs to hang out at one of the other bars downstairs and just shoot the shit with the bartender who is a friend of mine and whoever else shows up while drinking soda (I go down to hang out not always to drink) and listening to bad kaorake. When my wife comes back tomorrow, we will hang out during the day and go back downstairs to the bar tomorrow to watch the Super Bowl. We have 8 vacations planned this year not including 5-6 trips to fly up to our home town in Atlanta (where we lived all of our adult lives until two years ago) for things going on in our friends lives and to fly to my child hood home to see my parents and family. Not bragging, most of our vacations aren’t anything exotic or expensive and I play the credit card point/sign up bonus/churnimg game to offset some of the costs. My focuses on how to add business value was what allowed me to find strategic consulting jobs where most jobs are still fully remote.

musicale 2y ago

> they match, more or less, those of UNIX's philosophy 1. Good design is innovative UNIX innovated by simplifying Multics - throwing away ring security and PL/I's memory safety features. Linux innovated by cloning UNIX, giving it away for free, and avoiding the lawsuit that sidelined BSD. 2. Good design makes a product useful Yet somehow people managed to use UNIX anyway. 3. Good design is aesthetic UNIX threw away clear, long-form command forms and kept short, cryptic abbreviations like "cat" (short for "felis cattus") and "wc" (short for "toilet"). Its C library helpfully abbreviates "create" as "creat", because vowels are expensive. 4. Good design makes a product understandable See #3 5. Good design is unobtrusive That's why UNIX/Linux enthusiasts spend so much time configuring their systems rather than using them. 6. Good design is honest The UNIX name indicates it is missing something present in Multics. Similarly, "Linux" is the gender-neutralized form of "Linus". 7. Good design is long-lasting Like many stubborn diseases, UNIX has proven hard to eradicate. 8. Good design is thorough down to the last detail UNIX/Linux enthusiasts love using those details to try to figure out how to get Wi-Fi, Bluetooth, and GPU support partially working on their laptops. 9. Good design is environmentally-friendly Linux recycles most of UNIX's bad ideas, and many of its users/apologists. 10. Good design is as little design as possible Linux beats UNIX because it wasn't designed at all.

grose 2y ago
Reads like it came straight out of the UNIX-HATERS Handbook, nice. (For those unfamiliar: https://web.mit.edu/~simsong/www/ugh.pdf https://web.mit.edu/~simsong/www/ugh.pdf)
- pjmlp 2y ago
  UNIX haters handbook exists, because many of us don't worship at the fate of UNIX church. Yes, it did some things right, but also did plenty of them bad, lets not worship it as the epitome of OS design, cloning it all the time without critical thinking. Alone the fact that its creators went on to design Plan 9, Inferno, Alef, Limbo and Go, shows even they moved on to better approaches.

gyomu 2y ago

Rams’ principles were perhaps noteworthy when he first vocalized them as the state of design discourse was much more primitive back then (not even sure of that actually), but today they ring quite simplistic and hollow, and kind of useless as actual decision making tools. “Good design is as little design as possible” ok cool but I have 30 different feature requests coming in every week from actual users, that doesn’t really help me make concrete design decisions “Good design is aesthetic” whose aesthetic? Aesthetic is extremely cultural and arbitrary, my designers are fighting over whether a photorealistic leather texture is more aesthetic than a gradient texture background, how does that help? “Good design makes a product useful” uh yeah okay I’ve never had a design problem that was solved by someone saying “you know what, we should just make this product useful” “oooh right how did we not think of that”. I mean these principles all sound good and high falutin’ as abstract statements, but I’ve never found them useful or actionable in my 15+ years working as a designer.

skydhash 2y ago
My takes: “Good design is as little design as possible” What you create should be a natural flow of what your clients needs to do. Don't go and add lot of options like a plane cockpit. Which usually means try to find the common theme and adding on top, and also clamping down on fantasy wishes "Good design is aesthetic" I'd take the definition of pleasing instead of beautiful for the term. When learning to draw, an often given advice is just to focus and detail only a single part of the whole picture, everything else can be left out. So discussion over a single thing is usually meaningless. If it's not going to be the focus point of interaction, as long as it meshes into the whole, no one care about the exact details. “Good design makes a product useful” Usability is a whole field, and you can find the whole corpus under the HCI (Human Computer Interaction) keyword. Focus on meeting this baseline, then add your creativity on top. > I mean these principles all sound good and high falutin’ as abstract statements, but I’ve never found them useful or actionable It's kinda like Philosophy, you have to understand what it means for yourself. It's not a cake recipe to follow, but more of a framework from where to derive you own methodology.
- lloeki 2y ago

epolanski 2y ago

> Good design is innovative Why? Maybe it's meant in an artistic sense, but under an engineering one I just don't see it.

scarface_74 2y ago
Artistic design leads you to the unnecessary skeuomorphism of iOS 1-6
- gamedever 2y ago
  that was vastly better than today's "guess which things are interactive" design where what's clickable/editable/interactable is just a guessing game.
  - wwweston 2y ago
    This. Stuff like stitched leather was obviously indulgent without a lot of function, but skeumorphic buttons at least carried a standard complement of affordances that too much flat design ignores.
idle_zealot 2y ago
If it's not innovative, then you're reinventing the wheel and would be better off using someone else's good design.
- cgh 2y ago
  From the article: "We are destroying software telling new programmers: “Don’t reinvent the wheel!”. But, reinventing the wheel is how you learn how things work, and is the first step to make new, different wheels."
  - idle_zealot 2y ago
    Reinventing the wheel is a great learning exercise, but it doesn't yeild great software.

0x1ceb00da 2y ago

> Good design is honest > Everything is a file

hannasm 2y ago
Is your interpretation that these two statements are at odds? What even is the intended meaning of "a file"? To me it could be: Something accessible via a file descriptor that can be read from and/or written to. Feel free to add some other details like permissions, as needed. Perhaps they should allow for folders as well, since a complex piece of hardware undoubtedly needs to expose multiple files to be robust, but the underlying intention was to create a standardized way of interacting with hardware. Sectors on disk, switches, analog devices like a speaker, i2c and other hardware ideas all need to be read from or written to in some form to be useful
- otabdeveloper4 2y ago
  Take a simple and obvious example - say, controlling a musical instrument from a computer via MIDI. Calling that a "file" is ... a humongous stretch, to put it mildly.
- tsimionescu 2y ago
  I think they meant that in any widely used Unix system today, there are a loooot of things which are not files, so the design is not honest. The most common example of soemthing almost all programs interact with universally is BSD sockets. In Plan9, which goes out of its way to follow this everything is a file philosophy, TCP/UDP connections are actually represented as files. You open a file and write something to it to create the connection, and then you read or write to other files to read the streams, and you write again to the control file to close the connection. On the server side, you similarly write to a control file to start accepting packets, and monitor a directory to check for new connections, and so on. Note that "file" here has a pretty clear definition: anything that can be interacted with using strictly the C FILE api - open()/read()/write()/close().
pinoy420 2y ago
> Good design is aesthetic > Xorg I guess it didn’t say pleasing?

frontalier 2y ago

why is it 10? why not 7 or 15?

MadWombat 2y ago

It seems to be one of those "pick any two" jokes, but those usually only have three items on the list. And yet pretty much everything on this list feels mutually exclusive.

hobs 2y ago
Everything had tradeoffs, but let's just list out things you called mutually exclusive: innovative vs useful, understandable vs honest, long lasting vs thorough, aesthetic vs unobtrusive, What?

khana 2y ago

[dead]

begueradj 2y ago

What is "good design" ? That's the question.

rapnie 2y ago

Based on UNIX philosophy too is Dan North's idea of Joyful Coding that does away with formal SOLID principles in favor of CUPID more playful ones: https://cupid.dev https://cupid.dev

blueflow 2y ago

The rules are too generic to be useful, because mankind still can't agree on what is "innovative", "useful", "aesthetic", ... and what isn't. Only rule 7. and 9. are measurable and not purely subjective.

makeitdouble 2y ago
And then rule 7. is debatable. If you design for an ephemeral state, it doesn't make sense to be long lasting. 3D printing a door handle that perfectly fits my hand, my door, the space it moves in and only lasts until I move to another house can be the ultimate perfect design _for me_. I'd see the same for prosthetic limbs that could evolve as the wearer evolves (e.g. growth up or ages) or what they expect from it changes.

lloeki 2y ago

This page has the 10 principles, along with a small text and a visual illustration for each one. https://www.vitsoe.com/us/about/good-design#good-design-is-innovative https://www.vitsoe.com/us/about/good-design#good-design-is-i...