Insights into Software Architecture and Testing Evolution
George Fairbanks delves into the evolution of software architecture and testing from the 1990s to the present day, discussing the shift from manual reasoning to a more testing-centric approach. The exploration of intellectual control, statistical control, and the impact on project development is captured through thought-provoking visuals.
- Software architecture
- Testing evolution
- Project development
- Intellectual control
- Statistical control
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Intellectual Control George Fairbanks O Reilly Software Architecture 2020 NYC gf@georgefairbanks.com @ghfairbanks
Me, programming in 1995 Smalltalk Lambdas, dataflow Unix, XWindows Object-Oriented Analysis, Design, & Programming 2-week delivery
Me, programming in 1995 Smalltalk <blink> NO TESTS </blink> Lambdas, dataflow Unix, XWindows Object-Oriented Analysis, Design, & Programming But how? 2-week delivery
Where does our confidence come from? 1995 Reasoning Manual tests confirm reasoning
Where does our confidence come from? 1995 2020 Reasoning Wide blanket of tests Manual tests confirm reasoning Reasoning is less critical (but still compatible) Some whack-a-mole development
Kinds of control Intellectual control (IC) Run the code: no Dijkstra Proofs Structured programming Beyond proofs Types, patterns, ADTs, DBC, static analysis, ...
Kinds of control Intellectual control (IC) Statistical control (SC) Run the code: no Run the code: yes Dijkstra % of state space Proofs Structured programming Many forms of IC
Testing numbs us to our loss of reasoning
How projects drift toward testing (SC) IC,SC IC,SC IC,SC
How projects drift toward testing (SC) IC,SC IC,SC IC,SC IC,SC SC
How projects drift toward testing (SC) IC,SC SC IC,SC IC,SC SC
How projects drift toward testing (SC) IC,SC SC SC SC SC
The limits of refactoring Refactoring preserves behavior IC,SC SC To redesign, we must understand the problem Empirically, refactoring isn t strong enough SC SC SC
Once lost, IC is hard to recover Gardening: easier to stay on top of weeding Effort is linear wrt # of plants Software: MUST stay on top of complexity Effort is superlinear wrt # of modules Loss of IC is usually a one-way street
Reasoning keeps complexity down Striving for IC lowers complexity Assumptions: Stay within complexity budget Seek simpler designs Simplify existing code 1. Complexity builds over time 2. Minds are limited 3. Problems have many solutions of varying complexity Daily decisions add up
Testing numbs us to our loss of reasoning
Statistical control numbs us to our loss of intellectual control
Zombie projects: dead but they dont know it yet Control SC IC + SC Zombies Time
Software architecture Single module SC and IC both work IC help from ADTs Information hiding State-based analysis Separation of concerns Consistency via patterns
Software architecture Single module Architecture SC and IC both work IC works best Huge state space, yet unit test to e2e ratio 1000:1 IC help from ADTs Information hiding State-based analysis Separation of concerns Consistency via patterns IC help from Views Styles Quality attribute tradeoffs Hoisting
What can we do? Keep IC high Culture of good, simple design Property-based testing Model-based testing
What can we do? Keep IC high Low IC? Ask: Culture of good, simple design Property-based testing Model-based testing Does process promote IC? Who is rewarded for helping IC?
1995 2020 Reasoning (Intellectual Control) Wide blanket of tests (Statistical Control) Want reasoning & testing Articles at: georgefairbanks.com/ieee-software
