On Monday I had a conversation about which fields to include in a database table in order to solve a problem within a problem within a problem. The reason I had this conversation is that last Thursday we were talking about a parent who has three children in ABA programs. So I started thinking about how our software might be improved in order to better support that person's needs, which led finally to Monday's conversation. (It's not solved yet - I'm still working on it.)
We all have our own personal horror stories of our encounters with "bad" software. It either doesn't work right, or doesn't do what we expect, or is hard to navigate or figure out how to get it to do what you need it to do. Or it fails completely.
For half a century now, humans have been struggling to find ways of making "good" software consistently. There are some great success stories. There's also an irony: the harder we try to make "good" software, the more people will complain that it's wrong.
Why is this?
Expert problem solving requires a kind of laser focus on the problem. So if we have really smart people focusing on "making good software", we will get good software. It will compile without warnings, meet all requirements free of any major defects, be modular in design and adhere to a well-constructed architecture.
But it's still not going to do what you, the end user, needs it to do - unless that's where our focus is. To do that we need to talk to the people who will use our software and ask them - is this what you need? Do you like this? Is it delightful to use? How can we make it better for you?
As it turns out, the methods we've developed to build the right software, also ensure we build good software.