Programmer Musings

Ease of Development as a Quality Metric

I recently been studying software architecture and have had a minor epiphany. My assumptions about code complexity may have been unnecessarily pessimistic.

From my experiences in software development, I have observed that more powerful or more robust systems are naturally more complex. A side effect of this observation is that beginning to do development on an existing system in this category required a relatively large startup time. I have observed talented and intelligent developers taking 4-6 months to learn a system well enough that they would do less harm than good when making changes or fixing bugs. I had come to accept this as a necessary evil of complex systems.

In reviewing the concepts of accidental complexity and essential complexity for the umpteenth time, I realized that I might have been setting the dividing line in the wrong place for the software systems I've seen. What if it takes 4-6 months to understand these systems because of too much accidental complexity. Maybe a good metric would be how long it takes a competent developer with knowledge of the domain to make positive changes to the code.

In Abbreviation, Accidental Complexity, and Abstraction, Reg Braithwaite does a very good job of explaining part of what I'm seeing. Some code may develop accidental complexity through the very mechanisms we are using to develop better code. Refactoring code inappropriately or removing duplication badly can result in code that requires way more brainpower to understand. This is can be an indication of lower quality.

Recently, I've been working with some substantial systems that are actually pretty easy to understand. I see things that can be changed easily, verified, and moved into production in a short period of time. I have seen some things that can be improved to fix potential bugs. I have also seen places where better abstractions would make the code more flexible and powerful.

I wonder if that last set of changes might be better left alone. This appears to be yet another facet of YAGNI that I just had not thought through well enough in the past. As I make changes, I need to make an effort to remain mindful of how difficult it will be for the next developer to make changes. Does this new abstraction really offer enough benefit to be worth the cost of learning the abstraction? Does the change increase the quality of the code, or just add abstraction for the sake of abstraction?

I have often weighed multiple alternatives to a design to determine the simplest. I have even used the YAGNI argument to suggest that a simpler abstraction is better than a complex framework. I have made trade-offs in design to support only what the requirements ask and avoid adding unnecessary flexibility. But, I've never actually thought about trying to reduce abstraction for the same reasons.

When a system contains only the abstractions needed to do its work, it is easier for the next developer to understand and change. I need to be more aware of this application of YAGNI in the future.