2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- April 7, 2010
- Rants
The biggest impediment to change is a cultural one. Change means things are going to be different and human beings resist this at some level. Change requires being able to adapt and this can be difficult so as a result we tend to resist it.
I often run an interesting experiment in some of my lab classes where I give students an assignment to build a piece of software but I only give them some of the requirements up front. The requirements I give them seem to lead them down one certain approach to design but later I give them another set of requirements that really requires them to change the design they initially adopted in order to accommodate the new features.
What I find is that few developers will quickly embrace changing their existing code because there’s a culture around not changing code. When we change code it becomes dangerous, that’s when bugs get introduced and we may not totally understand the code even if we wrote it ourselves. Changing code always represent some level of risk.
This fear of changing code is absolutely antithetical to where our industry needs to go. We need to build up the confidence to be able to write software that we can then later change or else our software will slowly cease to provide value.
To build the confidence to change code we must adopt practices that support us in writing code that is changeable. Most importantly, having unit tests in place gives us a safety net so that if we make a mistake or introduce a bug we find out about it immediately through a failing test. With a suite of unit tests in place the resistance to changing code begins to fade and we become more confident in changing the code, which in turn lets the software continue to deliver value for customers in the future.
Previous Post: « We Can’t Keep Starting Over
Next Post: Test Driven Documentation »