Interesting question. I think it depends on the perspective. Are you the developer, the architect, the IT manager, or probably most importantly the business owner, or business user? I think it is also worth separating out two concepts – quality and value. You might have software that is considered to be poor quality by those qualified to assess quality – but valuable by those qualified to assess value.
For example, a loan origination system might consist of the most unmaintainable code, crappy deployment process, and legacy platform, but because it delivers business value there is no need to change – until the quality starts to impact the ability to deliver that value. Reminds me of a quote – if it is worth doing (value), it is worth doing half arsed (quality).
From a developer/architect/IT manager perspective, quality software would have the following attributes:
- The system structure is open to change over time.
- The system performs as defined by accepted requirements.
If you look at those two simple things, there is lots of hidden detail. For example a quality system structure that can be changed over time means that the code is well factored and there is appropriate coupling and cohesion between the units (being more generic and not assuming OO). You might actually break the system up into different sub-applications to allow some parts to be replaced entirely. For example, you wouldn’t build an e-mail marketing system into a loan origination platform, but you might synchronise some data via a set of well defined contracts. So you could change between say Mail Chimp to Campaign Monitor fairly easily.
Being open to change over time also implies that you can roll those changes out without major disruption, where is where Continuous Delivery and build/release automation comes in. As with anything, our definition of quality will change over time because a lot of those concepts didn’t exist (or weren’t broadly recognised) in the mid-range space until the last decade or less.
When it comes to requirements, that implies that you have a process that you can use to tie back changes in the system to system requirements. This is where tools like TFS give you a good advantage in terms of end-to-end traceability. At the very least I think organisations should try to standardise on a set of tools that they can integrate to give them some measure of analytical capability over the assets they are managing. After all, you wouldn’t work with a stock broker who couldn’t associate your customer records with the trades that they are performing on your behalf.