April 25, 2015
Non-Functional Tests Can Help Avoid Over-Engineering (And Under-Engineering)
Building on the topic of how we tackle non-functional requirements like code quality, I'm reminded of those times where my team has evolved an architecture that developers taking over from us didn't understand the reasons or rationale for.More than once, I've seen software and systems scrapped and new teams start again from scratch because they felt the existing solution was "over-engineered".
Then, months later, someone on the new team reports back to me that, over time, their design has had to necessarily evolve into something similar to what they scrapped.
In these situations it can be tricky: a lot of software really is over-engineered and a simpler solution would be possible (and desirable in the long term).
But how do we tell? How can we know that the design is the simplest thing that a team could have done?
For that, I think, we need to look at how we'd know that software was functionally over-complicated and see if we can project any lessons we leearn on to non-functional complexity.
A good indicator of whether code is really needed is to remove it and see if any acceptannce tests fail. You'd be surprised how many features and branches in code find their way in there without the customer asking for them. This is especially true when teams don't practice test-driven development. Developers make stuff up.
Surely the same goes for the non-functional stuff? If I could simplify the design, and my non-functional tests still pass, then it's probable that the current design is over-engineered. But in order to do that, we'd need a set of explicit non-functional tests. And most teams don't have those. Which is why designs can so easily get over-engineered.
Just a thought.
Posted 6 years, 3 months ago on April 25, 2015
Navigation
Blogs I Read
Sections
Third-Generation Testing
Agile Development
Apes With Hobbies
Application Lifecycle Management
Apprenticeships
Architecture
Back To Basics
Bletchley Park
Boffoonery!
Books
Codemanship
Code Smells
Complexity
Continuous Inspection
Education
Events
In The News
Innovation
Legacy Code
Metrics
Microservices
Multithreading
Music By Programmers
Site News
Nonlinear Management
Podcast
Post-Agile
Products
Professionalism
Reality-driven Development
Refactoring
Reliable Software
Requirements
Small Teams
Software Craftsmanship
Software Process Improvement
Test-driven Development
UML
User Experience Design
Agile Development
Apes With Hobbies
Application Lifecycle Management
Apprenticeships
Architecture
Back To Basics
Bletchley Park
Boffoonery!
Books
Codemanship
Code Smells
Complexity
Continuous Inspection
Education
Events
In The News
Innovation
Legacy Code
Metrics
Microservices
Multithreading
Music By Programmers
Site News
Nonlinear Management
Podcast
Post-Agile
Products
Professionalism
Reality-driven Development
Refactoring
Reliable Software
Requirements
Small Teams
Software Craftsmanship
Software Process Improvement
Test-driven Development
UML
User Experience Design
Props: