Ask HN: What Makes Software Great?

A great software is one that does what it needs to do without surprises. Nobody like surprises. Like what makes a light switch great? I should be able to toggle the light safely and reliably.

Unlike a light switch a software does not live in a static environment, so it must be able to keep changing.

A software is like a plant, you want stability (no surprises) and adaptability within the resources that are available.

I believe a good piece of software is like any well made tool. It fulfills a single purpose, elegantly and simply. It is closed for further modification, but open for easy extension.

I can reach in my tool box and take out a socket, that will fit a torque wrench, breaker bar, or ratchet. I can easily see exactly how it works.

Great question! From the top of my head in no particular order:

- It is reliable

- It is focussed

- It models its domain well

- It is efficient in its interactions and use of resources

- It scales the patterns of interactions to the proficiency of its users

- It is fast

- It does not break compatibility of its interface without reason

- It is intuitive

- It is well documented if documentation is necessary

- It is accessible and international

- It is open (source)

- It is extendible

- It has a community around it

- It helps users to understand the domain and possibly extends the common understanding of that domain

- It works in the best interest of its users

- It does not lose data

- It fails gracefully and explains reasons for failure clearly

- It does not contain ads

- It fosters creative solutions to problems

Software that does 'one thing well', as per the UNIX philosophy[0]

[0] https://hackaday.com/2018/09/10/doing-one-thing-well-the-uni...

> Of course it needs to work for its intended purpose. But that alone does not make great software. That is merely table stakes.

I disagree and it's probably illustrative to explain why.

The worst engineers I've ever worked with have all been obsessed with the idea of software rather than what it accomplishes. Modular code, readability, efficiency: all are means to an end. Good engineers will do these things in proportion to their utility to the end goal.

In contrast, there's a legion of engineers who right this very instant are more concerned with onboarding processes, whether their code has the right subjective shape, what the linter rules are, and whether there is enough content on the company blog. Don't be one of them. Build useful things and don't "play software engineer." People who do work on building software will be too busy to care about ephemera and they'll achieve excellence because that is what is required of them.

Put another way: if working software is just "table stakes", raise the stakes. There is no better way to improve the objective quality of your software than to make it do more for the user or have it do it better. It is the reason for code to increase in quality.

My favorite answer to this question: https://youtu.be/-UKEPd2ipEk

Good code follows some base set of standards, works, and can be updated/replaced/rewriten easily (simple to understand scope).

Great Software is like a well made power tool

  1> easy to understand
  2> reliably does what you expect
  3> works well with the compute power you have available, doesn't waste it
  4> works well with accessories, in a predictable manner
  5> can be applied in a wide range of situations, without breaking above

Great operating systems are like using an electrical outlet

  1> Easy to understand
  2> Supplies only the resource you expect, and nothing else
  3> Stops the load if it tries to gobble up resources
  4> Doesn't let the load send things elsewhere(like a ground fault detector)

The question can be split into the user experience for developers vs the business parts of the process. I don’t think the 2 can be entirely divorced while thinking of what makes software good. Good engineers would want their software to be well crafted but it’s always a trade off between how you’re delivering value to business by making it work right for your users vs making it right for developers. A good software strikes a balance between the 2 in a way the delivers business value while not killing developer productivity in the long run.

Then there are aspects that are related to code. In those terms code that is consistent (follows team agreed definitions on naming conventions, code formatting, styling etc), APIs that are guaranteed with well written tests so that developers can develop with confidence, has good infrastructure for common idioms such that the developers mental burden is taken off of the how to do and focused on what to do are the things that come to my mind.

[dead]

Great software feel obvious, it does not hide what it is doing, and where abstractions occur they are explained and they use descriptive structures and variables. Great software does not require you to learn something complex or non-trivial just to use it for a trivial task. Great software follows standards where standards exist, and follow conventions without variation where no standards exist. Great software is written securely, and where security issues are being handled great software doubles down on being obvious, documented, and documented with examples. Great software rarely comes from corporations, great software tends to come from lone programmers or lone teams with a non-trivial history developing together.

I like the quote “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

I think great software is all about organization, code should be predictable. Legacy code should not become a problem over time, it should provide a solid foundation for growth. Poorly organized code will set you up for failure.

You are conflating good software with good workflow. You can have great software with terrible a code base. You can have a great code base and developers and have terrible software.

Two totally different topics really, but narrowing down what question you are trying to ask seems more important here.

With that said, I think a good code base is necessary if you don’t have good software yet. You need to be able to try things in a relatively painless way so you can iterate.

Software can also be good and bad at the same time. AWS is great for scaling, but terrible developer experience. Things can be both things at once, or even three things (their codebase could be immaculate, or not).

Seems like a trite conversation when we try to generalize it. Everything is so case-dependent with this stuff.