Everyone wants change. We all want to thrive for excellence and reach for the top and whatever else your motto/slogan is. But when it comes time to make the hard decisions, you’re paralyzed. Change paralyzes people. Scared and stunned, we cower back into our illusionary comfort zones.
“Change is inevitable”, “The only constant thing is change”, “(mad laughter here)”… I’m not exactly talking about that kind of change. While the principles still apply in the software context. It’s interesting how the principles apply in multiple facets of life.
You can throw all the buzz words around, as much as you want. Social networking, Web 2.0, “we’re forward looking”, “emerging technologies”, but this is all lip service. Put your code where your mouth is, and eat it. Redo it, rebuild it, go through a process of rebirth. Because if you don’t, you’ll die. You’ll become sidelined and insignificant. You won’t be able to carry your own weight and you will collapse under it.
So stop talking about it, and adopt it. Be willing to adopt it. You don’t always have to change, but you must always be willing to adopt change. That’s one of the biggest mistake software companies make, they lock themselves in. Developers write code, and they’re joined to it at the hip. It becomes their baby, and to suggest that it should be changed is off-limits. Management will in turn back these developers, because they wrote the system, they know how it works. So management is scared they’ll leave or pout if change is suggested and they’ll lose the knowledge base. So first of all, hire people who not only take pride in their work, but also take ownership. Hire developers who will own their code and the code of the entire team. And when the times comes, they’re willing to say, “oh yeah, I frakked this up. Let’s do it again, let’s do it right. Anyone have any ideas?”.
Instead, the software industry is littered with people who, on the suggestion of change, will look at you as if you just killed their dog, and then the neighbour’s kittens. Developers don’t just build features into software, they also build in job security. If someone checks in job security into your software, fire them.
But this is not the only case where people freeze upon the mention of change. There’s also the issue of “but we have software live, we can’t begin to change portions of it, we’ll lose money!”. Yes, this is true. But you have to take off your short-sighted spectacles at some point. You’re already losing money by not changing. So take a few developers, branch off the code base and let them go nuts. Keep maintaining your existing software and either make incremental changes, or in the case where you change wholesale, develop an upgrade path.
It’s okay to experiment. One of the factors that prevents change is that management wants sure fire change. They want massive guarantees, and plans and details to the extreme before any work starts. While this is okay if you’re building bridges in sky scrapers, for software sometimes you just have to make the changes. The TDD folk will disagree on the onset, but you know exactly what I’m talking about. You can’t just phantom out of thin air what changes are required or what changes will fix things. You have to tinker and play with the system to find out. Sometimes you have to make the change to see if it works. This scares management (and some developers even). People want decisions in the confines of a meeting room, afraid to deal with the unknown, afraid to take chances and afraid to move forward. To say, “we’ll have to look that up and get back to you” is like admitting defeat. Well, it’s time to accept defeat.
Once you know there is a problem, get people to fix it. Don’t have the resources? Well then, make time for one person for a day a week. Start simple, but present opportunities instead of blockages. This should be management’s primary goal. If your best people are bitching about problems, listen to them. If they’re suggesting change, listen to them. They know better than you, that’s why they’re working for you, that’s why you hired them. And if you don’t trust them to know better, then fire them. But stop pretending to want to improve and take real steps towards change. Listen very very carefully to your best people.
There’s no better way to kill innovation and creativity than to continually resist change. Stop resisting.