WHAT IS "GOOD" SOFTWARE?
1. It should work, be used and useful.
- Meeting software development schedules, budgets and formal requirements with software that the end users consider a millstone around their necks - is NOT a good thing.
It is important to flush out screen GUIs and identify awkward functionality with the end users, as part of alpha or beta testing.
2. Design and Code should strive for ease of understanding. This is much more important than performance, reuse, generality, terse coding,...
- This often means that the software should have right degree of "generalization" for the problem and budget at hand.
-
The less the programmer understands the application domain or the likely paths of change - the more complex their software.
- Software that is overly generalized for unlikely changes and unlikely code reuse is NOT a good thing (see programming joke).
- Reducing a chaotic set of requirements to simple categories, and then coming up with an easily understood, obvious design - takes far more up front thought than an overly generalized (and therefore overly complex) solution.
The ultimate test of good software is whether it lives on (to be used, useful and enhanced) well past its originators.
3. The most common pitfall: is when developers get more hung up in how code is constructed - than in the end user functionality they are delivering.
- In the end, the average customer doesn't care if an application is developed in GWBASIC, Visual Basic, C#, or Assembly for that matter, as long as it looks good, runs good, and works well.
- Among modern programming languages, debugging capability is much more important than language particulars.
- "Yes, but it has great internals" doesn't cut it when basic functionality is awkward and/or buggy.
- I have seen Information Services (IS) organizations get so hung up creating infrastructure, that they effectively forgot to create/support sellable products.
- Once again: it is important to flush out screen GUIs and identify awkward functionality with the end users toward the end of development - as part of alpha or beta testing.
- This step is often given short shrift or skipped altogether (i.e., "we have a spec, right?"), but in my experience - there is just no getting around it. You can tell if it's been skipped from the user frustration afterwards. Some common examples are:
- From the way one pages through pdf documents (the scroll bar keeps hiding) to finding the Control Panel (you'd better already know the name of what you are trying to search for before you search for it) - Windows 8 has NOT been good software.
- iTunes has also been enhanced into utter user unfriendliness. The last time I tried to use it (to burn an audio book to CD) there wasn't even a "home" button.
THE CHALLENGE
The challenge of creating "good" software is to make everything as simple as possible - but not simpler.
... and when it comes to software: making simple things complex - is easier than - making complex things simple.
Gettng people is agree on what "good software" is - goes a long way towards being able to cohesively work together.
Copyright ©2014 by Ken Freed. All rights reserved.