You're perfect! Don't change a thing

In our group's architecture meeting recently we (developers) were given a warning about code changes effecting (or is it affecting?) production. To sum it up we were told: "do not make changes unless they were absolutely necessary or be aware of consequences". And I'm wondering are there really any of us sitting at our workstations trying to think up changes to the system that aren't necssary? That aside though I'd like to examine the paradigm that this kind of warning is really introducing.

One thing to always remember as a software developer is that anytime you make a change to any system you are taking a chance of adversely effecting said system. Yes, there is a chance you could break something since no one and no system is infallible. So what do we do about this? Avoid doing our jobs? I guess before we can address that we have to define what it is we do as software developers.

Developers have a simple job. Write code to deliver software that performs requested functionality. No matter where you are or what you are developing this applies. It's simple I know. Too simple. But there are so many strings attached to that job description that you really can't sum them all up in a job posting of any sort. You have to consider that the code being written on day 5 is not going to 100% valid and in scope on day 35. Imagine the difference between requirements on day 5 and day 605. Software is a process. It has to grow which means it has to change. Scope changes. System requirements change. User requests change. The older a system gets the worse the code smells; no exceptions. So while a developer is in charge of delivering functionality they also have to consider these things: scope change; code maintainability; scalability; stress handling; and even the probability of the application surviving a complete system failure (or being usable after a zombie attack).

That being said, a developer knows that systems are going to require change. There are going to be changes that are directly related to user request and then there will be those changes required due to the need to *gasp* refactor (thank you Martin Fowler).

Sometimes its as simple as updating or migrating to a new tool in our application. A couple years ago we switched from using EJB2 to using a Spring container for our framework, it wasn't a user request, but we needed to change from using EJB2. That needed to be done for many reasons which I won't go into here. It required a lot of sweeping code changes. There were a lot of hiccups along the way some of which we're still running into. But it didn't end the world as our application knows it.

There are other changes though. Changes that aren't directly linked to upgrading or migrating tools. For instance, your application has been in development for 4+ years and is still growing. There are parts of the framework that are duplicated due to original configuration and short sighted development choices. Or even just the fact that code pool x is just to freaking big to manage and needs to be broken into smaller more manageable components. These changes won't offer any direct value to the end user (on the surface anyway), but they contribute to a cleaner more efficient code base. And a cleaner more efficient code base helps keep an application running smoothly, contributes to easier maintenance of the application, and also helps keep good developers sane (which is a good thing, insane developers do insane things like blame their tools for all their problems).

So, do we avoid these changes for the sake of what is stable now? If we do that it only helps those stable apps for now. What happens when that currently stable application in production needs a new feature or has a bug that needs fixed. Now you have to work in the mess that should have been cleaned up months or even years ago. Now making what should be a simple change is like trying to add a new floor to a four story building, but you have to add the floor in the middle of the building, not the top.That means that the chance of introducing more bugs into the system is multiplied (the risk is already there just because you're making changes in the first place). The change will probably take longer than it should. And on and on we could go with this.

Developers write code. Developers make changes to make the system better (for performance and maintenance). It is risky. That's a risk we're willing to take.

Until next time,
Les