Live data from Hacker News

Dieter Rams' design principles applied to software engineering

github.com

21–30 of 63 posts

Re: Dieter Rams' design principles applied to software engineering

#21

Earlier quoted context omitted.

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.

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.

Re: Dieter Rams' design principles applied to software engineering

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

Re: Dieter Rams' design principles applied to software engineering

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

Re: Dieter Rams' design principles applied to software engineering

#25

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

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.

Re: Dieter Rams' design principles applied to software engineering

#28
post #4

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.

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

Re: Dieter Rams' design principles applied to software engineering

#29
post #20

Earlier quoted context omitted.

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.

Re: Dieter Rams' design principles applied to software engineering

#30

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

Post reply on HN