DEV Community

Discussion on: A New Architect’s Take on O’Reilly Software Architecture Conference

Collapse
 
jsetiawan profile image
Julian Setiawan

Thanks for the insight. Regarding the more nebulous illities, I certainly agree that lacking a functional requirement makes them harder sells. For quality and maintainability, do you have an opinion about using metrics from testing or static code analysis? I know they are controversial and can be gamed, but seem tricky to track otherwise. I'm also interested in trying out Adam Tornhill's techniques where complexity itself is not inherently bad, but complex code that is constantly changing and associated with bugs may be.

Collapse
 
elmuerte profile image
Michiel Hendriks

I have a love-hate relation with metrics. They require a lot of work to use. You cannot simply enforce rules like a maximum fan-in or cyclomatic complexity. Breaking up something because it goes over a certain metric just slightly is just wasting effort.

A lot of thing within a (physical) library are about books. Almost everything refers to books, that does not make the design of 'book' bad, just a place which has a lot of impact if it needs changing.

Looking at metrics over time is where things are becoming more interesting.

Talking about Adam Tornhill, his book Your Code as a Crime Scene is on my to-read list.

Complexity is only a problem if we need to deal with it. If no one needs to read or modify a particular part of the code, does it really make a difference whether it’s complex?