CODEMASH 2009

CODEMASH 2009 was again another great experience. I want to thank my company Click4Care for letting go for a couple days and Pillar Technology Group for letting me crash in the massive suites they had reserved! I think the pillar squad had more fun pairing with each other in the room then they did at the conference. I have to say it was really fun and they are some real nerds. 

Last year scripting was a big theme. Groovy, Ruby, Grails, and Rails took the conference by storm and this year was a continuation of that but did transition the baton more to functional programming (fp) languages like Scala and Erlang.

Concurrency was a keynote last year and with CPU clock speeds flatlining and more cores being injected concurrency was now the focus of atleast a few sessions this year. Ugh… I have come to a place with concurrency. I have a feeling that the best concurrency is the threaded code that didn’t have to be written at all. Find another solution! It’s just ugly. Just do it when there is no other way out of it.  I noticed in the conference that if you do have to do concurrency you may find yourself picking up a fp language in order to ease the pain.

Lunch with Venkat Subramaniam

During the last day at CODEMASH I had the pleasure of having lunch with Venkat. Venkat has authored such books as “Practices of an Agile Developer” and “Programming Groovy” and is a really fun speaker to listen too. Venkat’s presentations are riddled with personal experiences that he’s learned from.

Venkat seems like a great guy and extremely down to earth. If you have a chance to hire him as a consultant or coach do it!

If you haven’t had a chance to hear him speak look him up. He’s not hard to find. If you are a software developer or a development manager and interested in adopting good practices founded by experience read Practices of an Agile Developer. You will most likely be happy you did.

Stumbling over legacy code

A wise man once said that legacy code is anything without a test. This pretty much means if it was written 3 years ago or even 3 seconds ago. This is true if you consider legacy code anything that is poorly designed or at risk.

I would say that approximately 80% of projects and software that I’ve worked on in my career have been knee deep in legacy code. Most of these projects were going into situations that the client didn’t have unit tests in place already. This can be a very tough situation for an agile developer because this usually means that the build may not be in a place for running tests or the project structure may not be conducive to automation with feedback loops for Continuous Integration (CI) servers to broadcast to a team.

Many times a project that doesn’t start with an agile approach will soon be consumed by the complexity of the design over time. Here is where the cost of change over time grows expeditiously and fixing or changing the code becomes more and more painful.

It seems much easier to start a greenfield project with a good project structure in place. A team can start with an automated build that is ready to execute unit tests and provide feedback on code coverage and quality before you write the first lick of code is ever written. Iteration zero can demonstrate that you are ready to produce value. While you are there, go ahead and connect the build up to a CI server like Hudson and integrate it with your source code repository.

If all that is done before there are dependencies it’s no sweat. Now break to my reality; me stumbling towards agility with legacy code. Everywhere I’ve developed software I’ve heard many of the same and sometimes pretty unique reasons why teams or individuals aren’t leaning towards agility practicing anything that looks remotely agile. Embarrassingly enough, I’ve created some pretty good ones.

What I have found is that you will never reach the final destination of agility but don’t give up because you have to start somewhere. Once you think you’ve finally arrived you will only be surprised by another reason to get back on the bus. For me, it’s a constant challenge. Good me vs. Bad me most of of the time. (Read Venkat’s “Practices of an Agile Developer”)

I have a list of thoughts I’ve compiled for encouraging others to start somewhere when it comes to working with legacy code.

1. If your team must write software let it be the best software your team can write.
2. If your team must change legacy code let them be the right changes.
3. Refactoring legacy code with test driven development is fun! It’s extremely challenging and I bet your death march buddies will feel the victory, doing the touch down dance, and thriving on the new found time they have because of the quality produced. Less defects are always a good thing.
4. Leave the world a better place. When you go into a class to fix yet another legacy bug, look for other improvements that will make the code better. Get atleast the low hanging fruit like unused variables, imports, and methods. Also remove some of that white noise like useless comments, commented out “future enhancement” code snippets, and fixing other noise issues that make changing code more challenging. When I fix a method I check it’s code quality with a PMD IDE plugin and it’s coverage with a EMMA IDE plugin. These tools are freely available! I generally like to eliminate all medium and high priority PMD issues and refactor the method until it has 90% + code coverage. There’s lots of tools out there to try out. The next person that has to work on that code will appreciate your hard work.
5. If the methods aren’t testable make them. Get skilled in making a method or class testable before you begin changing it. Write a characterization test to protect it’s current behavior. Then, refactor the method to make it testable. An example is taking out instantiated objects out of a method that are evaluated and effect the testability of the method. If you take those out of the method you can set their value outside of the method and allow the method to either call for it or accept it as an argument. You may also enjoy the use of reflection for invoking private methods or to get/set private fields. You can also extract out code that could be in it’s own method. This is very common and extremely helpful when refactoring.
6. Unreasonable deadlines equate to things not getting done on time. This is no excuse to write poor code. You will be left with more of a mess in the end when still not making the deadline. It’s also possible that bitterness toward your employer will grow and begin to effect your craftsmanship. Take pride in what you produce and allow yourself to be excited to release it!
7. If death march driven development is what your team’s accustomed to, try to figure out the real problem. This may mean changing your estimation process, breaking work down into smaller chunks, time boxing legacy bug fixing, fixing architectural flaws, eliminating heavy processes or frameworks, and anything else that may be specific to your culture or development environment that is hindering agility or causing death march syndrome. Unfortunately, this expose those who thrive on death march development. It makes them feel heroic because of the “effort” and management even passes out the Scooby snacks for this. The problem with this is that it’s based on hours spent versus outcomes or value delivered. In the end, if what’s produced is the most important thing, do it right without killing yourself or taking others down with you.
8. Teams that want more agility should consider first what not to do. You may find that there’s no way possible to add any new practices to your already overly burdened team. Well, if you’re already over burdened you should take a load or two off your shoulders. Consider the things that you are doing that are not valuable to produce the required outcome. You may be doing some of these things out of practice or “methodology” only because it’s on your team’s SDLC diagram. Always question your team discipline and practices or lack thereof.
9. Being a developer is riddled with decision after decision, line after line of code, method after method, and integration after integration. Take the time to make the right decisions along the way. This right decision will try to fit into the time and budget and will for sure deliver what’s required without compromising the quality of the value delivered.
10. Know your code intimately. Emerge your code with tests. Start with a single small requirement, a little test, and a little code to pass that single test. Refactor the code to make it better and repeat those steps often.
11. Isolate and conquer. Most of the time refactoring legacy code with unit tests will provide proper focus and clarity. However, there are times when the legacy code you are working with is too large and too noisy. This sometimes invites isolating the slither of code that’s causing the problem and fixing it outside its normal inhabitance. Then put it back. I generally don’t like when I have to do this so it may not be that good to do. You may consider what it would take to first make the code less noisy.
12. Help others. The more everyone is making the code better the faster you will all succeed.

Simply said, there may be many challenges to start driving agility in the refactoring of a legacy application. Don’t look at the legacy application as a bunch of constraints as to why you can’t commit to making it better. Instead, embrace the challenge of making it better  one legacy fix after another.  You will always own that choice. Have fun with it.

This is not by any means an exclusive list of what to do. If you’d like to know more about making code better read Bob Martin’s book “Clean Code” or Michael Feather’s book “Working effectively with Legacy Code” for more ideas.