June 8, 2014
Reliability & Sustaining Value Are Entirely Compatible Goals
This is a short blog post about having your cake and eating it.The Agile Software Development movement has quite rightly shifted the focus in what we do from delivering to meet deadlines to delivering sustainable value.
A key component in sustaining the delivery of value through software is how much it costs to change our code.
The Software Craftsmanship schtick identifies primary factors in the cost of changing software; namely:
1. How easy is it to understand the code?
2. How complicated is the code?
3. How much duplication is there in the code?
4. How interdependent are all the things in the code?
5. How soon can we find out if the change we made broke the code?
By taking more care over these factors, we find that it's possible to write software in a way that not only delivers value today, but doesn't impede us from delivering more value tomorrow. In the learning process that is software development, this can be critical to our success.
And it's a double win. Because, as it turns out, when we take more care over readability, simplicity, removing duplication, managing dependencies and automating tests, we also make our software more reliable in the first instance.
Let us count the ways:
1. Code that's easier to understand is less likely to suffer from bugs caused by misunderstandings.
2. Code that is simpler tends to have less ways to go wrong - fewer points of failure - to achieve the same goals
3. Duplicated code can include duplicated bugs. Anyone who's ever "reused" code from sites like The Code Project will know what I mean.
4. Just as changes can propagate through dependencies, so can failures. If a critical function is wrong, and that function is called in many places and in many scenarios, then we have a potential problem. It's possible for a single bug in a single line of code to bring down the entire system. We call them "show-stoppers". It's for this reason I dreamed up the Dependable Dependencies Principle for software design.
5. High levels of automated test assurance - notice I didn't say "coverage" - tends to catch more programming errors, and sooner. This makes it harder for bugs to slip unnoticed into the software, which can also have economic benefits.
So there's your cake. Now eat it.
Posted 7 years, 2 months ago on June 8, 2014
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: