←back to thread

917 points cryptophreak | 5 comments | | HN request time: 0s | source
Show context
squeedles ◴[] No.45761639[source]
Good article, but the reasoning is wrong. It isn't easy to make a simple interface in the same way that Pascal apologized for writing a long letter because he didn't have time to write a shorter one.

Implementing the UI for one exact use case is not much trouble, but figuring out what that use case is difficult. And defending that use case from the line of people who want "that + this little extra thing", or the "I just need ..." is difficult. It takes a single strong-willed defender, or some sort of onerous management structure, to prevent the interface from quickly devolving back into the million options or schizming into other projects.

Simply put, it is a desirable state, but an unstable one.

replies(22): >>45761688 #>>45761787 #>>45761946 #>>45762556 #>>45763000 #>>45763132 #>>45763419 #>>45763515 #>>45764215 #>>45765589 #>>45766183 #>>45766281 #>>45768514 #>>45769691 #>>45771196 #>>45771307 #>>45771846 #>>45772026 #>>45773411 #>>45773951 #>>45776266 #>>45779651 #
DrewADesign ◴[] No.45761787[source]
Overall, the development world does not intuitively understand the difficulty of creating good interfaces (for people that aren’t developers.) In dev work, the complexity is obvious, and that makes it easy for outsiders to understand— they look at the code we’re writing and say “wow you can read that?!” I think that can give developers a mistaken impression that other peoples work is far less complex than it is. With interface design, everybody knows what a button does and what a text field is for, and developers know more than most about the tools used to create interfaces, so the language seems simple. The problems you need to solve with that language are complex and while failure is obvious, success is much more nebulous and user-specific. So much of what good interfaces convey to users is implied rather than expressed, and that’s a tricky task.
replies(8): >>45761895 #>>45762139 #>>45764045 #>>45764889 #>>45766812 #>>45767103 #>>45767301 #>>45774902 #
zahlman ◴[] No.45764045[source]
> I think that can give developers a mistaken impression that other peoples work is far less complex than it is.

Not at all. Talented human artists still impress me as doing the same level of deep "wizardry" that programmers are stereotyped with.

replies(2): >>45764136 #>>45767695 #
1. cenamus ◴[] No.45764136{3}[source]
Trust me, there are enough people here that believe that.

Other engineering disciplines are simpler because you can only have complexity in three dimensions. While in software complexitiy would be everywhere.

Crazy to believe that

replies(1): >>45766376 #
2. analog31 ◴[] No.45766376[source]
There are many more than three "dimensions" if I may use the term loosely, in software or hardware engineering.

Cost, safety, interaction between subsystems (developed by different engineering disciplines), tolerances, supply chain, manufacturing, reliability, the laws of physics, possibly chemistry and environmental interactions, regulatory, investor forgiveness, etc.

Traditional engineering also doesn't have the option of throwing arbitrary levels of complexity at a problem, which means working within tight constraints.

I'm not an engineer myself, but a scientist working for a company that makes measurement equipment. It wouldn't be fair for me to say that any engineering discipline is more challenging, since I'm in none of them. I've observed engineering projects for roughly 3 decades.

replies(2): >>45770863 #>>45771772 #
3. swader999 ◴[] No.45770863[source]
The top three are typically quality, budget and time. Usually a compromise is needed on one of these. You could replace quality with features in SW dev.
replies(1): >>45776347 #
4. cenamus ◴[] No.45771772[source]
I think the poster literally meant x, y and z in terms of dimension
5. nradov ◴[] No.45776347{3}[source]
Scope is more of a dimension than quality. In theory it might be possible to accept lower quality in order to cut the budget or accelerate the time but in practice that doesn't seem to work. Any significant reduction in quality usually causes the project to grind to a halt after the prototype stage. You just can't build any new features when everything is broken.