Dieter Rams' design principles applied to software engineering | Hacker News Reader

Dieter Rams' design principles applied to software engineering

github.com

161 pointszedr60 comments

Funny! I wrote the same article 6 years ago: https://www.dein.fr/2015-10-01-10-principles-for-good-code.h...

> Companies that stay successful are the ones which don’t fear to constantly disrupt themselves through technological innovation.

Spot on, intel immediately comes to mind. Will playing it safe always lead to mediocrity though? Depends i guess, heard that a good poker player loses less often.

(edit) Enjoyed reading the rest of the article too. In the environmental impact section i missed the idea of using more efficient languages though.

Loved your article "Learnings from six months as a first-time engineering manager" too. I was instantly reminded of the documentary on Michael Schuhmacher on Netflix i watched yesterday. I couldn't care less about Formula 1, but still think that it is an amazing movie and great role model for good leadership. He was asked over radio after he won the championship: "How do you feel?" There are several seconds of silence. He answers: "Ross you are the best. You guys are all great. We did it." I thought: "Wow, he puts the others before himself. A great example of a good King after the theory of archetypes by C.G. Jung"

Companies that are successful are the ones that meet the needs or desires people have. Some of those change a little and some a lot. Some it’s tweaks and others it’s wholesale change. It’s not about the technology, it’s about the people

There's a difference between disrupting yourself and not playing it safe.

Good poker players don't exactly play it safe. They play very cautiously most of the time, but very aggressively when the odds are in their favor. And sometimes they bluff on top of that.

funfact: Andy Grove had a blurb on the cover of "The Innovator's Dilemma", that coined the term "disruption".

Seems to be mixing up software with code.

    > 3. Good software is aesthetic
    >
    >    Take a moment to step back and look at your code. 
    >    It should look beautiful to you. 
    >    ...

It's not that the code quality doesn't matter, but this is just apples to oranges.

I'd go even further and say code is pretty strictly a liability. If you don't hate your code enough to throw it away and replace it on a whim, then you've made it more important than it should be. Why else would we encourage things like loose coupling and building upon abstractions? That thing you're abstracting away is likely to be thrown away at some point and replaced with something different.

I can understand feeling pride in your work and all that, but let's not pretend--the code I write today is probably best viewed through beer-goggles, not in a wedding dress :D

While I think the core of your idea is right, some could understand it the wrong way:

> If you don't hate your code enough to throw it away and replace it on a whim, then you've made it more important than it should be.

You shouldn't write code you hate just to avoid attachment. What you should do instead is to develop the ability to (as product designers tend to say) "kill your darlings". You should love the code you create, but you should love the freedom even more that comes with being able to wipe it away with one stroke. Like sand drawings in a zen garden you should accept that nothing is ever final and don't let the things you created excert power over you.

You can also be proud of what you created as well, not because the thing is the thing it is, but because you made it and you were happy with how it turned out under the circumstances of the moment, maybe you even learned some things. Circumstances and the whole world change (including you), so what you created might not be up to the task anymore, you might be able to create something even better, more reduces, more clear, etc.

And you can feel all that while still happily throwing away your code. It is not a contradicition.

I hear you, and I agree. There are a lot of subtle factors that go into designing good software. And even if you could write code that never needed to be rewritten or thrown away, the desired outcomes change over time anyway, so eventually you just end up with a really nice paper-weight. Still, if you go out of your way to write crappy code you'll end up with a crappy outcome.

This submission broke the rules for "Show HN" - this is reading material, not a project people can try out and play with. We've taken "Show HN" out of the title now.

https://news.ycombinator.com/showhn.html

If I follow this it would take me 9 months to build a signup form.

I wouldn't mind...

But if I were the CEO/Manager/etc. I guess I would mind.

The real question is how long the next login form after that would take you. A day?

Good design is not lost once you are done with it. The lessons learned when following through with such things stay and ultimately enable you to build more better things faster.

This speaks to me, but it's hard in a corporate environment. I've been fortunate enough to have some kind of leverage on this and the payoff is huge even if not immediate.

Love that!

> 8. Good software is thorough down to the last detail

That's my approach. It tends to earn me a bit of scorn, but I do it anyway.

Question. Are those people scorning you because you are thorough down to details, or because you are thorough down to details _at the cost of something else_?

Mostly because they assume that it's at the cost of schedule.

In my case, that turns out not to be the case. I work very quickly.

I can develop a fairly "full-fat" iOS app, with a lot of functionality, in less than a week. I do it all the time, with test harnesses.

But getting the app to what I consider "ship" shape, is another matter entirely, and can stretch the project to a couple of months (which is still not so bad, all things considered).

One of the nice things about my approach, is that I can start using TestFlight (Apple's beta-test service for iOS) quite quickly. This allows non-tech stakeholders to start actually using the app, very early in the process.

If I have an open-ended schedule (like I do, with the project I'm working on now), it's amazing, because we can refine the project, and work through a lot of the MVP stuff, without the public shame.

> Mostly because they assume that it's at the cost of schedule.

How can you change that assumption?

The only way is the way that I've been forced to work, my entire life.

I'm a high school dropout with a GED, and some rather spotty tech training.

That means that I have had to fight, claw, and prove myself at every single step. No easy slopes for me. Double-black-diamond, the whole way. Very darwinian. Exhausting.

Fortunately, I don't have to prove myself to anyone, anymore. I am working with a bunch of folks that have known me for years, and are quite aware that I'm "for real." I don't make a dime, and don't really care. I enjoy the work.

Kind of a relief, really.

Thanks for that context. I am still curious - How can you change what other people assume that you think is not correct?

I guess I don't understand the question.

I can't prevent other people from assuming anything.

I have a portfolio, with complete, start-to-finish repos of many shipped projects. If no one wants to review it, then there's nothing I can do.

You sound like a good person to learn from. Do you have any video tutorials about your process (how you go about building complex applications in such a short time, what you prioritize, how you plan your work days etc.). I am also curious about the resources you used to build up your developer & project management skills.

I've done training and whatnot for years. Last bit I did, semi-professionally, was a Core Bluetooth class for try!Swift World[0], [1]. Been quite a while, since I've done any classes.

I also have a lot of writings and whatnot, on my personal site[2].

Frankly, I spend most of my time writing production code, so I don't break off too often, to refresh my blog. I should actually do something, soon. It's been a while since I came up for air.

[0] https://www.tryswift.co/world/

[1] https://github.com/ChrisMarshallNY/ITCB-master

[2] https://littlegreenviper.com/miscellany/

Thank you for the resources. I've read some of your posts, and I found them useful, insightful, thought provoking, and pleasurable to engage with. Also, it looks like you are passionate about beautiful and thorough documentation, to a level which frankly I don't remember seeing in my 15+ years of engineering. I find it quite inspiring. When you say your work is high quality, you're not bragging or exaggerating. I admire your thoroughness and attention to detail, and hope to learn from you.

I must say that I wonder how much work you need to put in to get to your desired level of quality. Excuse my bluntness, but would you consider yourself a workaholic? Also, I find it odd that you say you don't make a dime from your work, even if it's mostly FOSS. Surely high quality work should attract high quality rewards.

Nothing to excuse. Perfectly reasonable question.

I’m definitely somewhat OCD. Not sure that I’m really a “workaholic,” in the destructive sense, as I actually really enjoy doing this stuff, and frequently take breaks to do errands and chill out. I suspect a lot of folks would not find my lifestyle attractive, but it works for me.

I am a bit “on the spectrum,” which makes me an excellent architect and coder, but can cause issues with my interpersonal relationships.

A lot of what looks time-consuming in my code and writing, is actually the level of habit, and just “flows,” without my having to think about it. I write well, and quickly. It has been my experience, that I generally outpace my teammates (break time!).

I’ve been writing all my life, and I come from a fairly well-educated and literate family. My younger brother and I are the “redneck engineers.” Everyone else has Ivy-League sheepskins. My older brothers and sisters have all published books and papers, and whatnot.

As far as rewards go, I would have been happy to work with others. I spent most of my career, on teams. It has been my experience, though, that few people want to work with me, mainly because I'm "chronologically-challenged." Some folks have been quite blunt about it, while most have been fairly weasely.

Others actually don't want to write high-quality product. It's a deliberate decision to embrace mediocrity and "barely tolerable" quality. It may sound ridiculous, but they make money; sometimes, quite a bit. It's hard to argue with results. As long as consumers are willing to pay for poor quality, there will always be a plentiful supply of dross. It can be argued that my development methodology is not cost-effective. I won't lose any sleep over it. I'll do it for free.

Not a big deal. I really enjoy doing what I do, and I don't need anyone else's approval or support, if they aren't willing to give it. It sounds "arrogant" (and I have often been told that I'm "arrogant"), but it's actually just "confident." I don't think I'm God's Gift to Programming, but I know damn well that I am in the upper percentile. I'm aware of quite a few others that are better than me, and I look forward to continuing to learn, and be humbled by the challenges.

I've spent my entire life shipping software. I'm not exaggerating. Here is the first engineering project I ever did[0], [1] (Download PDFs). I architected it, designed the hardware and electronics, wrote the firmware OS, and the host drivers. My very first project was a top-to-bottom hardware/firmware/software design project. It was used in an ATE system for "DC-to-Light Super Bearcat Scanners," made by the company I worked for, back then (they would not be a big deal, these days). That company is long dead.

That same "on the spectrum" thing, means that I also work just fine, alone. I have to greatly reduce the scope of my work, but I can get quite a bit done, all on my lonesome. The project that I'm working on now, is an example. It's the kind of thing that usually is done by a team of engineers.

[0] https://littlegreenviper.com/TF30194/TF30194-Manual-1987.pdf

[1] https://littlegreenviper.com/TF30194/ATE-System-Driver-Manua...

You sound like a great hire to me. A lot of people in tech are somewhat challenged (in one way or another, and usually in several) when it comes to dealing with other people, so I don't see this as a disqualifying trait.

But since you are good at turning ideas into polished products, what about your own ideas? I'm talking about simply creating "catchy" apps and selling them on the App Store. Is there a good living to be made this way, with a skill level like yours? Can you get any predictable/consistent success? I'm guessing no matter how good an app is, you still need a fair bit of luck to get it seen by a lot of people (or perhaps the "right" influencers) to make a hit out of it. And yet when you see something simple and catchy like FlappyBird, made by some seemingly random guy in Vietnam, it seems obvious to everyone other than himself that millions would buy it. I wonder how many nice and catchy little apps like that never catch the big wave, and die after getting downloaded by a handful of people.

I’ve released over 20 apps on the App Store, since 2012, but none have taken off. TBPH, I haven’t really tried. My free Bluetooth sniffer apps seem to be fairly popular, but I am not really in a hurry to start making a ton of money. I don’t really need it, and I mostly release stuff to stay in practice. I think I’m down to only three or four apps, now: https://littlegreenviper.com/AppDocs/

I also have a bunch of OSS SPM modules: https://riftvalleysoftware.com/work/open-source-projects/

This one is fun: https://riftvalleysoftware.com/work/open-source-projects/#RV...

The spinning picker view is a very cool idea indeed. It looks like the kind of thing Apple could end up "sherlocking" :)

You would think so, but I keep not using it in my projects.

It's a very "in your face" UI element. It's the star of the show, and I have a personal philosophy that UI should remain in the background, as much as possible.

This is why waitstaff at restaurants often wear black uniforms.

The checkbox widget[0] has actually been far more useful to me. I use that all over the place (In its SFSymbols form, so it looks like a Mac checkbox). I'm not a fan of Apple's UISwitch widget.

I will, eventually, do SwiftUI versions of these widgets, but I'm not in a hurry.

[0] https://github.com/RiftValleySoftware/RVS_Checkbox

Well, the coin has two sides. People that have the same mindset, appreciate when someone strives for perfection and creates somethimg really good. But i learning to be fine with 97% was very valuable too i think. It can get problematic when stuff needs to be delivered fast though. Finding the right niche is key i guess.

Most people seem to be content with good enough and that is fine too. Diversity makes it fun somehow, there would be way less to discover and learn if we were all alike.

Maybe striving for greatness instead of perfection might be a way?

P.S.: Bookmarked your stuff last time you commented about testing harnesses and stuff. Haven't done iOS work in years and may never need it. I treasure a work ethic like yours, keep it up.

Thanks so much!

It's a labor of love, and I feel that makes all the difference. I like to think of what I do as a "craft."

You are more than welcome.

That is a great mindset IMHO, it makes a huge difference when you pour love into your work.

"Perfect is the enemy of good", or something akin to that, is also good to keep in mind.

True but "good enough" under too tight deadlines is what leads to security vulnerabilities.

Yup. Also, data-mining by non-tech staff. So many of these breaches, are because some marketing person took a dump of the data, and stored it on an open AWS instance, while they mined it.

Maybe I should add a few

1. Good software is carefully balanced

a good software is created when the user requirements are carefully balanced against resource and time constraints.

2. Good software is joyful to handle

A truly good software should invoke the child like playful and joyful instincts in the users.

There's one difference though. Unlike product designers, software engineers will never be in the spotlights. Not at Apple, anyway.

E.g. tell me how many times you've read an article about Jony Ive versus about an important software engineer at Apple.

John Carmack?

They did say "at Apple".

But Carmack is from a generation where developers were often still working on something on their own.

I do see a shift to a model where developers are viewed more as a commodity and less as artists. In a "just throw more developers at the problem" kind of way.

"Shift"?

It's been around long enough that seminar works on management calling the practice out are disregarded by some as outdated just by age

Everybody wants to commoditize their complement. This includes managers.

It feels like the trend right now is that developers are more expensive than managers. So if they’re a commodity, it’s the most precious kind. If the power dynamic keeps shifting that way though, I bet we’ll see some more like artists and less like cogs in the machine. Maybe not so much artists and more like other professionals.

Unfortunately, having a unique ability is no guarantee for not being treated like dirt, history tells us. E.g. look at how women have been treated historically up to recently.

At Apple? Maybe not. But elsewhere?

Maybe no articles written about them but books or chapters ([0], [1]) written by them.

In the spotlight? You betcha, i think watching talks by Brian Cantrill is highly entertaining. Rich Rickeys' talks are highly regarded on HN (making a mental note to watch them). Carmack talking at Quakecon for hours about many different things.

(edit) formatting and links

[0] https://www.amazon.com/Coders-Work-Reflections-Craft-Program...

[1] https://www.amazon.com/Masterminds-Programming-Conversations...

> At Apple? Maybe not.

Chris Lattner (inventor of LLVM and Swift) was pretty prominent when he was at Apple. He got stage time during at least one keynote and was well known in the macOS/iOS community. Not to mention that their engineering leads in general get to present their work every year to the devs who will be using it during the WWDC sessions.

Glad to be proven wrong! Learned some iOS development years ago but are out of touch what is happening in the appleverse at large, no snark intended.

The most recent SWE in the mainstream spotlight I can think of was Notch, the author of Minecraft. I don't know if the engineering is super-noteworthy, but it was good enough to make a very valuable product in a short time with few people.

Some of these apply better than others, but holy n4. That's the most necessary point of this post IMO.

`Code isn't "clever" if no-one understands it.`

It will make some code-bros mad though.

Cool !

I always wonder what modern UI would look like guided by these principles... I am a full-stack product designer.

Controls with visible borders, maybe

How about accessible, consistent (minimal design changes), efficient and fun to use.

The Linux Mint team did a blog post on changes in a new version. The tweaks on the design were really subtle, increasing contrast here and there to improve access- & readability. Back then i tought: "So what?"; now i think this is the correct way to do it.

My guess it would probably have to be native clients. It's hard to see how browser based clients can fit many of these principles better than a native client.

The best would be a native executable with no required server component.

Amazing! I've just recommended Dieter Rams: As Little Design As Possible book on LinkedIn.

Good design is needed everywhere. It's much more than adding a gradient to a Buy button.

Nicely put

Prepares to be downvoted...

Why are these supposed to be special? Everyone would agree with these in theory but the problem is not lack of these principles, the problem is how to actually use them in a fast moving business with imperfect tools, imperfect knowledge, imperfect employees and changing goals.

If you looked at my systems, you might say I am not following the principles but I was and am, they just don't always work very well in real life.

I think what you might be getting at is that Dieter Rams is a great designer because he is a great designer.

Almost everyone agrees with all or most his design rules. I can agree all day but that doesn't mean I can execute my designs anywhere near as well as he did during his career.

> Everyone would agree with these in theory...

Not me - when I read "Take a moment to step back and look at your code. It should look beautiful to you", my bullshit detector goes off full-tilt. The last person I want reviewing code is someone who wants to apply this principle (I don't so much care if they think this while writing code, if and only if it has no tangible downsides in what they produce.)

This is compounded with the following sentences "Beauty often embodies many useful properties. Code that pleases the eye is often readable, idiomatic, and expressive", as if pursuit of this undefined beauty causes these outcomes.

I am not sympathetic to arguments that this is true "in a sense", as this just adds subjectivity and circumlocution to an issue that should be, like good code itself, as straightforward and to-the-point as is possible while getting the job done.

A lot of people don't (really) seem to agree with number two here:

> 2. Good software is useful

The UNIX philosophy highly prioritizes simplicity (number 10 on this list), and there's always been a large group (and still is) of programmers that interpret this as "sacrifice functionality for the purposes of simplicity".

This changes the game for me. Well done.

Reply on news.ycombinator.com