16 February 2014

Software Quality is More Than Just Code Quality

I'm astonished how many people in our software business try to improve systems by JUST looking at source code - and ignoring loads of other aspects. Especially vendors of code analysis tools tend to equate "software quality" with "code quality" - which ignores major parts of quality issues. Let me illustrate my point with some examples.

Sample 1: Gold-Plated System

The team has created features above features, all highly configurable with a good-looking user interface. There's a button here, a menu there, some choices and a lot of functions... all stuff adding no business value, not useful for the end-user. By the way - all written in clean-code. In my opinion, this team produced *waste* - and the resulting system will more expensive to maintain than it needs to be - more lines of code, more configuration, more difficult to understand.

Sample 2: Overly Complex Solution

Data from a relational database is selected, then transformed into Java objects, then into an XML representation. This XML is processed into a pdf document, which is send via smtp-mail to the user. User prints the pdf, fills out some fields, scans the pdf. The system performs OCR (optical character recognition) and transforms back to xml. The xml is converted to Java objects, which are used to update the relational database. Sounds crazy? Is crazy - but describes an existing system. All written in nice and clean code. In my opinion this sample describes a conceptual disaster, where refactoring code alone wouldn't help - re-architecting the overall process would be the right approach.

Sample 3: Horrible User Experience

A company opened their impressive and useful backend services to customers by adding a web-frontend. Both back- and frontend code was written by expert programmers, adhering to many clean-code principles. Unit and integration tests supported the system. But the user interface has a nightmare. Layout, colors and screen flow had been created by programmers, not by usability-experts. Sidenote: I'm quite sure you have experienced similar situations... programmers-as-designers seems to be a common anti-pattern in development.

Software Quality is MORE than Code Quality

The examples above hopefully illustrate the point that even with well-written code a system can *fail* for its users or developers. Quality attributes like performance, understandability, maintainability, understandability, security or compliance might be neglected despite good source code...

Analyze Problems From Bird's Eye Perspective

In exiting business systems you should approach *improvement* or system evolution from different perspectives, not only by counting code-violations or code-metrics. For example the following perspectives provided valuable input for some of my own practice experiences:
  • Qualitative Analysis (e.g. ATAM)
  • Runtime Analysis, e.g. performance and resource monitoring
  • Analysis of Development Process
  • Data Analysis - find improper structures and content
  • Issue-Tracker Analysis
  • Static Code Analysis

Clean Code is Important...

I'm convinced of the importance of understandable code. I will actively promote refactoring towards cleaner code whenever appropriate. The principles of clean code need to be taught and practiced throughout our industry. But hopefully you see my argument - there's some more to do: we need to create understandability on a higher level, need to design appropriate technical and business concepts, need to design appropriate data structures and interfaces and so on...

Methodical Improvement to the Rescue

What's needed to systematically improve software is an iterative approach to find *many* problems, not only within code. aim42 collects practices and patterns to achieve exactly that - the foundation for systematic improvement. Think about it when some manager demands compliance to some code metric or coding-convention... you might be better off by optimizing or improving something completely different.

No comments: