Sample 1: Gold-Plated SystemThe 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 SolutionData 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 ExperienceA 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 QualityThe 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 PerspectiveIn 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