Agile Zone is brought to you in partnership with:

In the course of his 30-year career, David Bernstein has trained more than 6,000 developers at hundreds of companies on how to improve their software design and construction. His company, Techniques of Design (http://www.techniquesofdesign.com), provides customized training, coaching and consulting to software developers and development teams around the world, enabling them to master essential practices, including Agile, Scrum, XP, test-driven development, design patterns and related techniques, for building high-quality software more rapidly. David is a DZone MVB and is not an employee of DZone and has posted 18 posts at DZone. You can read more from them at their website. View Full User Profile

Resistance to Change

01.17.2013
| 1466 views |
  • submit to reddit
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.

Published at DZone with permission of David Bernstein, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)