A couple weeks ago when I gave my “Lessons Learned” talk at the Cleveland Day of .NET, I took some really good questions and wanted to share one here.  During my talk, someone in the audience described a pretty horrible situation at her job; a project that was behind schedule, overbudget, management won’t allow proper development practices to take place and everything had to be done NOW.  Unfortunately, projects like that seem to be pretty abundant.  Anyway, her question came down to this: what could she, as an individual developer with very little power in the organization, do to improve things.

Honestly, my first response was to tell her to quit because we all have to realize that there’s a point at which we can do nothing except deal with a horrible situation or find a better place to work.  For the woman that asked the question, she had no choice but to stay since she was working on some kind of visa (H1b?).  At the time, I simply told her to change what she could change.  Even the smallest things can have an impact on the larger organization.

The subject came up again at the May 22, 2008 Microsoft Developers of Southwest Michigan meeting.  Josh was talking about “worst practices” in an organization when someone in the audience asked pretty much the same question I had gotten in Cleveland.  After hearing Josh’s response and having time to think about it, here’s what I’d say if asked that same question again:

Things you can do

First, there’s not much you can do when it comes to the budget, but you can do something about being behind schedule and using proper development practices.  You need to set the example. 

Be an evangelist.  Find others that share the same values as you within the organization.  Sometimes having someone else to share the burden can help.  After all, if you find others that know the importance of “doing the right thing”, you won’t be the lone crazy guy in the corner mumbling about his red stapler, right?

Write unit tests for your own code.  Hell, you don’t even have to check them in.  Write them first, write them last, just write them!  Doing so will give you confidence that *your* code is doing what it’s supposed to be doing.  When you start cranking out solid fix (or change) after solid fix (or change), other developers (or even management) will start wondering how you’re doing it.   At that point, take them aside and show them the benefits of writing unit tests.  Remember, even the smallest changes can have an impact on the larger organization.

Setup your own continuous integration server.  Some people might debate this one, but I honestly believe CI works for a single developer all the way up to large teams (in fact, we discussed this on twitter a few weeks ago).  Can’t get the hardware?  Use a virtual machine.  Locked down and can’t install stuff on your own system?  Make friends with someone who can.  

Use source code control.  Is your employer not using source code control?  Install a local copy of subversion or git (or even Visual SourceSafe) and use it for your own changes.  Locked down and can’t install stuff on your own system?  Again, make friends with someone who can.  There is absolutely no excuse to not be using some kind of source code control system.

Set milestones for yourself and stick to them, but don’t be a hero.  Keep track of your tasks, your estimates and the actual time it took you to complete the task.  Use this information when you develop future estimates.

Don’t let the small things get in your way.  Sometimes it’s better (and easier) to ask for forgiveness than it is to ask for permission.  If you want to improve the way things are, you have to be willing to take some risks, BUT (of course there’s a but)…

Dealing with the decision makers

Technically, you don’t even need to tell anyone you’re doing the things I described above, but if you want to make any inroads within the larger organization and make it a better place, you need to learn how to communicate with the people that are making things difficult to begin with.

Ask.  Yep.  It never hurts to ask, right?   You can start off by asking if you can do some “proof-of-concept” work within your organization.  Start simple.  Ask if you can start writing unit tests.  You might be surprised at the answer you get especially if they (management) don’t have to do much.  Write your tests and then ask about standing up a CI server.  If you hit some resistance, find out what the problem is and try to work around it.

Get a copy of Carnegie’s “How to Win Friends and Influence People” (and read it).  As cheesy as the title is, it’s actually a pretty good book that gives a lot of good advice.  It’s a really quick and easy read.  There is a course that goes along with the book, but I wouldn’t recommend it (bad experience when I *tried* to sit through the course about 10 years ago).

Learn how to communicate the benefits of TDD, CI, etc. in non-geek terms.  Learn how to communicate the benefits of TDD, CI, etc. in terms the decision makers will understand.  Explain how it can help the bottom-line (because that’s what they care about).  Explain how it can help you write better software faster.

Be prepared to back up what you’ve been doing.  At some point, someone may (will) challenge you on the things you’re doing.  Someone will tell you, “but this is how we’ve *always* developed software.”  Don’t back down.  Explain the benefits of what you’re doing.  Point them to blogs, articles, screencasts and books on the subjects.  Show them the gains you’ve made and how their software has improved.

Be prepared to leave.  If you believe in what you’re doing and are told to stop even after explaining the benefits in non-geek terms , you have a tough choice to make.  You can back down, crawl back to your cube and accept that your life at that company will always suck or you can move on to a company that appreciates what writing good software is all about. 

In the end

Remember, we work to live, we don’t live to work.  Do what you can do to make things better.  I believe this applies to every facet of life, not just work.  Do what you can do to make things better.  Change what you can change, but be willing to stand up for what you believe in.

Special thanks to Sarah for reviewing and providing some great feedback for this post.