Soft as in "Software" - part II (The Fear of Change)

In my last post I described my epiphany about the way the business looks at IT (or at least one very possible look) and left off just before I described the common reasons for delivering crappy software. So here they come:

• Fear of change
• Rigid structure

First, and probably foremost, is the fear of change. The uncomfortable feeling every one of us has felt at one point or another (probably more likely at a lot of points, but may be that's just me ;) ) in his career when he has to change something in code that has been in production. Will it work with all the other components that are deployed? What about the bug that we fixed last month, does it affect the fix in any way? What will happen if it does not work, can I go back to the old version of the code?

These are all questions which we are often quite uncertain about how to answer. How can we eliminate this discomfort?

By building quality in our products and continuously inspecting them for that quality - with unit testing, integration testing, and acceptance testing.

Having nailed down the behavior of your software this way gives you a lot of confidence and eagerness to continue improving and developing your software. Do the green bars mean that you are 100% safe? Definitely not, but now you have a base which will free your mind from trying to remember all the little things you need to make sure your software works as you expect. If you take the time to keep this base growing as your code grows it will allow you to go quite far. The alternative I have seen is where you reach a point where you cannot go any further and remain sane, and then it is time to start over (or the "big refactoring" comes ... ). Time for the bullies to go asking for investment in rewriting.

Next, the Zen of software development ...

15.12.2008 | Comments [1]
Flokkur: Agile | Forritun
Höfundur: Petar Shomov