We’re a big brand in an even bigger company (who are, of course, owned by an even bigger company) and one of the most common complaints you get from software developers at big companies is that these companies are resistant to change. I have never agreed with this; I’ve always been able to instigate change and get my ideas heard. From middle management to upper management, when I’ve tried to make a good case for something they’ve almost always listened. When they didn’t agree with my opinion or didn’t think my idea was worthwhile, at the very least I came away with a good counter-argument and the feeling that they took me seriously.

It wasn’t until I saw Developer X in action that I began to realise why so many people have problems changing things in big business. And as it turns out, he wasn’t alone in his unhappiness at our processes either. When the inevitable reaction to his constant belittling of our processes and standards took place, seemingly content developers went on the defensive and started to pass the blame up the management ladder and proclaim “this isn’t how I’d do things if I was in charge” and the popular “I’ve been saying that for years but nobody listens.” What’s important is that these guys were agreeing with him that there were problems.

Managing your Manager

In the post-mortem that followed, it was clear to me that it’s not your opinions or your ideas or your solutions that matter, but how you present them to those in charge. As Steve McConnell writes in Code Complete, to get change you have to educate your manager:

“Managing your manager” means that you need to tell your manager what to do rather than the other way around. The trick is to do it in a way that allows your manager to continue believing that you are the one being managed.

The best long-term solution is to try to educate your manager.

It sounds simple enough, but whilst anyone can teach, it takes certain skills to become a good teacher. One of those skills is a thorough knowledge of the field, so that on top of sharing that knowledge they can also respond to questions effectively and apply the lesson to relevant areas that students can relate to. The other skill they have is the ability to communicate with the student effectively. And this is where I think many developers fail. Chances are if you find it difficult to get managers on board with your ideas, you’re missing one or both of these essential ingredients.

Or your ideas stink! I mentioned before that I’ve generally never had problems getting my ideas heard or changes made, but that was only half the truth. I’ve had my fair share of failures as well. Nobody will ever have a 100% rate, in fact more than half my ideas have been rejected within minutes because they have been flat out terrible (learning how to deal with that is for a different post). But even when it’s a good idea, it’s never as simple as just having an idea. There is a process to it all. Good idea or bad, over the years these simple steps for initiating a dialogue of change have served me well:

1. Confirm the problem isn’t you
2. Communicate the problem to the team
3. Come up with a solution
4. Present the problem, not the solution, to management
5. Propose the solution to the team
6. Persevere

Now, before I break down each step there is one last thing that’s important. Nothing will ever happen unless you actually raise the alarm when you’re unhappy with the way something works. This might seem obvious, but it’s incredible how many people would rather just bitch and moan about their manager or make constant sarcastic comments about quality of code rather than actively try and improve the working environment. This first came to light when members of our development team came out of the woodwork when the shit had hit the fan and claimed that the problems existed for years when I had never heard them suggest a fix for anything.

You have no right to complain about your job if you haven’t made the effort to make things better for yourself. Making a commitment to change and having the passion for the job in the first place is always the first step. That being said…

1: Confirm the problem isn’t you

When Developer X joined our team he displayed all the warning signs of a guy who would refuse to adapt. He ignored our coding standards. He ignored our coding guidelines. He repeatedly reinvented the wheel when someone else had solved the problem, because he knew a better way to do it. I could go on and on. The point is that this same developer turned every team catch-up meeting into an argument about our poor processes and the fact that we wouldn’t change. There is nothing worse than a hypocrite.

When you see a problem, you need to ask yourself - is this a real problem or is this just a difference in opinion? The question that was always asked of Developer X when he raised a ‘problem’ and solution was “how does this solve the problem in a way which is more effective than the current solution?” and he consistently had no answer other than getting angry and shouting something like “this is just the way I’d do it.”

The first rule of getting people to change is that you have to meet them in the middle. If you aren’t willing to change for them, why should they change for you? Choose your battles, bite a few bullets and make sure that there really is a problem that needs solving. Else the problem will just be you.

2. Identify and communicate the problem to the team

As I said before, more than half of my ideas have been rejected within seconds of them being proposed. Half of these rejections were because my solution was inadequate, but the other half were because it turned out that there was no real problem to begin with. Save yourself the embarassment of this happening to you by making sure to identify the problem before you come up with a solution. From now on you need to treat the two like completely seperate things. What you want to do is solve the problem as a team, not push your solution on the team at all costs.

Solving the problem as a team is the key, it gets people involved and confirms that yeah, other people agree that this is an issue worth raising. Perhaps it was raised before. Or perhaps solutions have been discussed but fell apart for good reason. Have faith in the fact that if this really was a problem, you’re working with talented people who have recognised this before and attempted to solve it. If you go on the offensive and start blaming the guy who wrote the code or came up with the faulty process (by process here I mean the processes behind creating software), it just makes you look ignorant. We’re all just constantly learning on the job, and there’s a whole bunch of bad code and mistakes with our names on it.

I’ve found that nearly every time I’ve brought up an issue with a fellow coder (who wasn’t Developer X) there was a perfectly good reason why they wrote it the way they did. On top of this, they will generally agree that it needs some work and they’d do it differently now. Some react more defensively than others, but this is where tact comes in and it’s important to reassure them that you’ve been there many times yourself. If it becomes a persecution thing then it only serves to create a hostile environment.

The same goes for the faulty processes, generally if you raise an issue with, for example, source control system or development methodology, there will have been a team discussion before you came along and some agreement will have been made about how best to continue.

One notable experience with Developer X was when he was incensed that we used CVS rather than Subversion as our source control system and came out all guns blazing about where we’ve failed as human beings. He was then politely informed that we’ve been having meetings about the limitations of CVS for several months now and there was a multitude of internal issues getting in the way of improving it. All he had to do was just ask the guy sitting next to him who had been there for ten years why we used CVS and he’d have been given the same information.

3. Come up with a solution

Developer X was never guilty of not having solutions (he had the answer to everything) but there were a few developers on the team whose sole job seemed like it was to point out faults and make sarcastic comments all day. It doesn’t help. At all. Coming up with a solution to a problem at the very least lets you know that the problem can be solved or that the existing solution can be improved.

Before you settle on a solution ask yourself this though - do I understand the solution completely? Not just technically, but in a way that you can present it to someone who won’t understand the jargon. Because the chances are you’ll need to propose the solution to non-technical management. When Developer X would come up with solutions, it seemed like he had spent all of five seconds formulating the answer. Essentially the first thing that entered his head, he would settle on. The minute someone raised a question or pointed out a flaw he would become flustered and struggle to deal with this unpredicted logic. If you run the solution through some tough questions of your own, you will be able to deal with these questions when the time comes to present it.

4. Present the problem, not the solution, to management

When you have a solution that you think is best, it’s still important not to get ahead of yourself when it comes to management. Although you must educate the manager, remember that McConnell also states that:

“the trick is to do it in a way that allows your manager to continue believing that you are the one being managed.”

By presenting only the problem, you allow the manager to digest the problem on its own terms and feel in control in the pursuit of a solution. If you present a solution immediately, he will only feel like you’re trying to take control and get defensive, I’ve seen many a good solution veto’d by the manager simply ending the meeting and deciding the matter closed.  This is no good to anyone.

By only raising the problem, the manager’s inner superhero kicks in and he feels a duty to help the poor inferior employee who’s come to him for help. Ultimately though what happens is that the technically incompetent manager has no solutions other than to delegate the responsibility. Rather than admit this, his first act of defence is to deny that there is a problem. Now here is the real difficulty - convincing a nontechnical manager that a technical problem exists.

The key here is not to tell them that the solution to your problem should make your job easier. Or more fun. Or anything that would even remotely make you happier at work. Managers don’t care about that, all they want is the job done and whether you use procedural spaghetti code or an MVC masterpiece… it’s all the same to them. But what they do care about is you taking so long to fix bugs. Or that bugs exist in the first place.

When winning over nontechnical managers to the ideas of Object Oriented Programming, I spoke to them in terms of time and money saved by reusing code and the effect it had on maintenance costs. When trying to convince people of Unit Testing, I explained that the process was designed to eliminate bugs and make maintaining existing code safer. With code reviews… free training! Everything was in terms of time and money.

When Developer X raised an issue and advocated a pure OOP approach, most of his arguments were boiled down to the fact that he worked this way before and couldn’t work any other way. There was nothing there about the benefits of OOP or why the concept was started in the first place. All a manager heres is a whiney runt trying to get an easy ride. Next!

5. Propose the solution to the team

When management has acknowledged that there is a problem and a solution needs to be found, they will of course delegate it. Now is the time to get the team together and propose a solution. Again, the goal here should be to get the best possible solution rather than your solution at all costs. If you went through the steps and got everyone involved and discussing the problem beforehand, then most people who care will have had a chance to think about it and come up with their own ideas.

It’s crucially important that this step is successful. A few years ago I proposed that I code a JavaScript framework to standardise our somewhat chaotic JavaScript scripts throughout our websites. As soon as I was given the go ahead to put my idea into place, not once did I consult with the rest of the team. It took me a few months to put the pieces into place and get testing done but eventually it was completed and presented to the team. Most of them liked it, but one other guy had started using a framework called Yahoo User Interface Library that had just been released. It blew my framework away completely. Within a couple of months, Prototype and then jQuery would present two more resounding reasons why the work I had done would inevitably go to waste.

After that, I made sure to canvas the opinion on every single developer before I ever tried to “build something for the team.” If you don’t ask their opinion or ask them to write some of the code, they will inevitably reject it no matter the results.

Another reason it’s important to get this right is that you don’t want to go creating more problems in an attempt to fix just one. Management has already taken the risk of creating extra work for the sake of “doing things right”, if you start to create personal problems between staff then the whole thing will be put on the backburner. Once an entire PHP project that my team worked on was completely abandoned because there was an argument between Developer X and every other member of the team about encapsulating configuration settings into an object and defining config values as constants. I wish I was joking, but that really happened.

6. Persevere

Just because a problem has been identified and a solution agreed on, it doesn’t mean that the time is going to be made available to put the solution into place. For me, this has been the biggest source of frustration over the last few years. The only solution is to persevere. When I finally got round to having Object Oriented Programming agreed upon as “A Good Thing”, no efforts were made to educate the existing developers (who all worked in Perl were the native OOP syntax is god awful) about the best practices. Nor was any enforcement made when people kept writing line after line of procedural code.

It was agreed that I should lead the charge having came from a Java background, but little to no time was given for me to create the basics of a framework to provide the tools necessary to make OOP worthwhile. Even though all our existing ‘framework’ code was stored in one massive monolithic Perl module, there was no doubt that it got the job done and the team was familiar with working that way. Splitting it up or replacing it required some dedicated efforts but time was never given.

Eventually I adopted the process of Guerilla Refactoring until the results spoke for themselves. When a manager applauded my work and asked:

“Why does your code have so few bugs?”

“Why is your code so easy to maintain or change?”

I simply told them that because I had taken the extra time doing it right, in the end I ended up doing it faster. Blam. A few weeks later my manager installed the Perl5 OOP framework “Moose” on to the production servers to facilitate the widespread adoption of OOP principals.

Change.

It’s a wonderful thing.

Me? I tend to go through a cycle of all three. One thing I realised from going on a few job interviews and looking at my list of complaints about my current work environment was that the problems I had were a veritable checklist of every working environment out there. Legacy code? Which established software company doesn’t have that? A standard set of tools and practices for common problems? I’d hope so! Changing something that isn’t broke?

There’s nothing worse than reinventing the wheel for no reason.

Except when you’re being asked to make major changes to a bunch of spaghetti procedural code full of inconsistent architectural decisions and quick-fix hacks for the numerous bugs that appeared since launch. Oh and could you improve performance whilst you’re at it? And by the way we’re already behind schedule. No manager wants to hear “complete rewrite” when they’re adding something that took the guy before you two or three weeks to hack in there.

So I hacked it in just that one time. And the next. And again. And in no time at all that horrible legacy code I used to blame on the other guy is now 50% mine. Oops! And those archaic practices and standards now dominate my CV .

Not my managers CV. Or their managers CV. My CV.

To top it all off, there has been a steady rise in web development jobs looking for expert OOP programmers and experience with MVC frameworks. It’s all Zend Framework this, Rails that and Django another thing. In my office we use Perl. And not even cool Perl like Catalyst or Template::Toolkit. We’re talking HTML::Template Perl here. I’m not even relevant in modern Perl jobs (all 2 openings per year).

Guerilla Refactoring

Guerilla Refactoring is a phrase I thought I had coined but was in fact soundly beaten. Essentially it’s the act of covertly fighting the good fight agains the almighty resistance of middle management, developing your own skills and getting better at your profession while you’re at it.

See, the biggest problem I had six months ago was that even if I could start from scratch and do a total rewrite of the code I was having to maintain, I didn’t have the real world experience to put all the theory into practice. Sure I knew what the acronyms MVC and DRY meant, but it’s not until you start trying to write truly reusable code that YAGNI and KISS suddenly become the acronyms of choice. The code behind a good API and simple interface can often be extremely complex, and it takes a lot of experience to get it right.

Things changed for me during the last major project I worked on. The existing codebase was so huge that no business case in the world could justify a complete rewrite of the existing code to achieve the stated goals of the project, on that issue I had admitted defeat. So there I was, hacking away on a OOP/Procedural mash-up with some hundreds of thousands of lines of legacy code when I found myself about a week ahead of the schedule with some time to burn. What I did next was something I did for the first time in my professional career - rather than alert my manager to my heroic ability to beat the schedule, I went back and improved the design of a piece of fully functional and tested code I had written. I believe they call it refactoring?

It was hardly a pioneering moment, refactoring is a fundamental concept to agile methodologies and OOP programming books across the land. But I work in an Enterprise environment and when a manager asks me what I’ve done and I show them a fully-functional solution, unfortunately their first thought isn’t “that’s great but I wonder if david could improve the code and incorporate some advanced techniques so he can outgrow us and get a better job”. In an enterprise environment, to improve the maintainability or scalability of a piece of working code you generally have a fight on your hands. If they know you’re doing it, anyway.

The refactoring I did was extremely successful, I turned 300 lines of procedural code into a completely reusable class. When the same problem inevitably came up a few days later at another part of the application, I trimmed yet more time off the schedule by plugging my class in there. The actual process of reusing the code raised some flaws in the initial design as well as some areas that needed improvement, so I went ahead and used the time saved to make those to my class. Coding at work actually started getting interesting again.

Soon I had the Guerilla Refactoring process down to an artform. I would solve whatever problem I was facing as fast as possible, then I would spend the rest of the budgeted time refactoring the design of my code and any surrounding code. My refactorings were subtle and isolated and I burnt my fingers on some misapplication of a lot of theory without having to commit to any major architectural decisions. Once a lot of those rookie mistakes were out of my system, I was having to do less and less refactoring because I was getting it right sooner. I became so confident in the long-term benefits of Guerilla Refactoring that it became less “guerilla” and more “public displays of affection for”.

We can’t all work for Google

If you’re lucky enough to be working in some small, dynamic and modern web development team with great seed engineers and all the latest and greatest agile practices then you probably scoff at the idea of having to go behind your managers back to do things right. But it’s the reality for most people working in the Enterprise environment.

Guerilla Refactoring works because you don’t break budget or blow a deadline by trying to rewrite an entire application when you were asked to solve a simple problem. Nor do you become responsible for an overblown and complex mess of an OOP architecture when you’re still wet behind the ears. You simply work within the time you’re allowed and go dark for a period of that time.

If the situation I was in is anything like yours, give it a try. It might just save your sanity. And your career.