Hacker News Reader

Comment by emingo | Hacker News Reader

The first comment on that page sort of made me face palm... but then it got me thinking.

"Simplicity of usage should always win over simplicity of coding. The purpose of a product is to solve the end user's pain, no one should give a dime about the engineer's problem. IMHO that was the genius of Steve Jobs, he could take any pre-exiting product and increase its complexity by 50x while simplifying its usage by 10x."

I am relatively new to coding, and really, I want to know what do you guys think about this? Does this really scale? Does simplifying the front end often compromise the backend?

View on HN

Its a false duality. It assumes complexity is zero sum, either the user has it or the programmer has it. In my experience this is not true.

But, doesn't maintaining both implementation complexity and product usage complexity low require either more development time or better developers?

Reducing either form of complexity certainly costs resources, but I think the point is that they are not necessarily antagonistic goals- they might even come as a package deal, to some degree.

There's a whole spectrum of users, as well. Programmers can be Python users, wherein the python implementation takes complexity hits to simplify it for the user.

It's all subjective, and the design of the high level concepts (maybe mechanics?) influence the complexity at every level below it. The idea of a 'file' goes from the GUI down to the hard disc format.

> Simplicity of usage should always win over simplicity of coding.

In a superficial assessment, yes, usage is the objective of software, and it should be as complex as needed to enable its users to have an optimal perfomance.

But then, most software is built in an environemnt where people don't even know* what problem they want to solve beforehand. Ading complexity too early makes it very hard to change your software and leads to a situation where you completely optimized some work that shouldn't be done at all, while the important work got harder because it was overlooked at first.

* They have a general idea, and even that is wrong sometimes.

I think that first comment completely misses the point of the article. It's not a matter of whether or not you should or shouldn't make things simpler for the user. It's that you shouldn't view changes as one-time costs - you need to take into account the lifetime maintenance cost of that change you will have to live with. Many times, it is worth the cost because it solves the end-user's problem, that's true. But the point is that we often don't even consider it.

It depends on what stage this is done at. Imagine everything is linked to a user. How hard would it be to allow anonymous posts?

In my experience, any interface that does not directly conform to the underlying technology is going to increase the amount of work (aka complexity). And typically, the reason why one interface is simpler than the other is because instead of conforming to the environment/language, the engineer had to code another way to do it.

>Does simplifying the front end often compromise the backend?

Sometimes but not necessarily unless you're making a programming language or a platform. For typical, more direct cases it's not necessarily the case at all.

Also based on his figures if you increase the complexity by 50x and simply its usage by 10x...you still made it 5x harder to use!.

The two are not mutually exclusive, and solving both of those is what makes programming hard and fun.

Reply on news.ycombinator.com