Agent of Change: Part 1 Preparation

Posted 2012-12-25
Written by Matt Frost
Category code

There are so many different processes, methodologies and tools; some of them good and some not so much. Every organization is different, has different needs and areas of focus; however I'd be willing to bet that most organizations don't have all the things in place to make them most profitable. There are developers at the 2 extremes, those that love what they do and seek to get most satisfaction from their jobs and those who are content to float by and collect a paycheck. One extreme embraces positive change, while the other will most likely oppose it. Understanding the extremes will prevent any interactions with these extremes from surprising you too much. Before we start changing the world though, let's prepare and get our pitch together.

Suggesting the right change

We all to make changes that make our jobs easier, so if your change isn't meeting a need or helping to ease a pain point, it's probably not the right change. It's important to be realistic, if you are a PHP shop and your suggested change is to "totally scrap PHP and have everyone learn Ruby on Rails" that's probably not realistic. Finding the right change for the right time isn't horribly difficult to spot, if you're attentive. Are you having issues with the quantity of bugs being found in production? What about issues providing documentation? Time entry? Communication of requirements? Find something that makes your job harder or less enjoyable, there's a pretty good chance that you aren't the only one.


We're going assume that your issue is with the number of bugs that end up in production, as it's a fairly common issue. As a developer, you speculate that Test Driven Development might reduce the amount of bugs and allow the development team to focus on implementing new features, so now what? Unless you're already experienced with Test Driven Development, you've got some work to do. What does Test Driven Development look like? Does TDD do all the things I think it will do? Why do teams that switch to TDD succeed? Why do they fail? What are the best tools for the language we work in? If we work with multiple languages is there one that is easier to start with? There are more questions I'm sure, but you have to be able to answer these. It's wise to seek out answers from the people knee deep in it, take to Twitter and find some people who are willing to share a bit about what they know on the topic. If you are going to suggest that a group of people completely change the way they work, it's probably a good idea to know what you're talking about...

The other side of this research coin, and really the only way to get the answers to a lot of these questions is to start writing tests. It's good to get all your dictionary definitions out of the way and have a conceptual understanding of TDD. Once you answer the question 'What tools are best to use?', you should start learning how to work with those tools. The awesome thing about Test Driven Development, as an example, is that you can use the struggles you already have to learn real life scenarios. Half the trouble with squashing bugs is finding them, learn to write tests that will reveal these bugs; heck the time you spend writing a test for how a feature is supposed to work is far more effective than var_dump debugging. The key is to learn the concepts and the tools as best as you can without burning out and without becoming a burden on your employer, it's a tricky balance.

Planning and pitching

Congratulations resourceful developer, you've found a pain point and some tools that might help ease some tension in this area. Not only that, but you've done your research and started using the tools to prove that they actually do make life easier. Well done! You aren't done though. You probably aren't in a position to say, 'We all know that we have an issue with the number of bugs that make it to production, so we are going to Test Driven Development starting Monday', and I think we'd all agree that's not an effective way to go about it. Edicts tend to get ignored or at least implemented half-heartedly and less than enthusiastically; build up some excitement. Find the developers that hate working on bug fixes all day long, build some excitement around the prospect of not having to do that as much. If you can find a few people with the same goal as you, it makes it easier; don't waste too much time talking to people who don't mind it.

All the research you've done and time that you've invested in learning a new tool will help you make your pitch. If you've used tests to quickly find and fix bugs in your organization, make note of those and make them part of your pitch. The more 'here is a time that this saved us money' over 'this will probably save us money', the more effective your pitch will be. Offices have different political environments and hierarchical structures, it is important that you operate within these structures and schedule time with the superior directly above you. The language of the conversation, again, depends on the type of organization that you are in, but it's important to frame the problem correctly. "Our code sucks because no one tests it" probably won't get you far.

It becomes a bit easier if the problem is well-known, "Boss, you know how we've been dealing with the issue of the amount of bugs getting to production? I have a few ideas that might decrease the amount of time to find them and bring the number of bugs introduced down". In most work situations, that's going to be pretty well received. If the problem isn't as well known, it might be a little bit trickier but as long as keep you the focus on the problem, you should be ok. This isn't a post about having conversations in politically charged environments, you know better than I what your workplace is like, as long as you stay professional and focused on how fixing the problem will benefit the organization, you'll likely make some headway.


When plans are well thought-out and researched, the element of risk that others perceive tends to dwindle. Hopefully, the organization that you find yourself in isn't politically charged and is open to constructive ways to make creating software more effective and efficient. Becoming an agent for change is about removing the barriers that you observe that make your job less efficient and less enjoyable. It's not about pointing out the faults of others in the organization or assigning blame, it's about learning and making positive changes from the lessons you've learned. Not all perceptions and observations are going to be received well, but if it bothers you enough to want to change it; stayed tuned...the next 3 parts of this series are going to help you through this process more. Research is not done overnight, take your time and build up a strong case for why this change is worth the effort!


Adam Culp


Very nicely said. Be professional.

Posting comments after has been disabled.