Author: James Kebinger

The project I’m working on right now is a collection of anti-patterns and just plain terrible code. The upshot of this is that its really hard to make it worse, and often times I can walk away feeling good about making a huge difference in making even small changes. My first project appeared well designed, and since I was new then, I felt very constrained in how much I could change. Not anymore, its like the wild-west in this code base, and any design is better than no design. Its definately been a good way to bust out of my years-long productivity slump.

The project was was started several years ago by an offshore contracting company (it seems like they got paid by the line) and then picked up by an in-house but still offshore team to continue to maintain and build. I don’t want to paint all offshore software-industry workers with the same brush, but in this case the code all appears to be written by people who just know how to program in Java. Barely. They just don’t think like computer scientists. For some reason no one seems to think a single class having five methods to do the same thing is bad. Or methods that are hundreds of lines long. Or building strings by concatenation, multiple times in loops that run thousands of times. Or checking for duplicates when copying the keys of a Map into a list. Converting Longs to Integers via a string object.

I’ve speculated that the current team must have come from a background of sustaining enginering (where the idea is to fix bugs in the least intrusive way possible) and that’s why they blithely copy the bad code around them. Either that or for some reason they don’t feel empowered to make changes.

The last few days have been especially great. I’ve been working on performance problems, and the code is so badly written that there are huge chunks of fat to chop out. Two methods I’ve found are O(n^2) so the profiler practically slaps you in the face, but they’ve somehow sat there for years. Replacing them with real implementations has reduced the time to run this code by 90%. Hours to minutes for large sets. That’s fun to talk about in meetings.

I recently became a believer in the value of unit testing. I sort of understood the benefits of the test-first approach academically, but always felt that what I was writing would just be too difficult to unit test (UI stuff etc). Before this, ed I think the last thing I unit tested in a formal, framework using way was this directed acyclic graph thing I knocked out for workplace. This project dropped the prospect of taking in a pile of data and at the end spitting out some numbers, which would be easy to test, but that’s not what got me there.

The former code that did similar functionality (ok, really the entire project) is a tangled mess of collections of fine-grained value objects that mostly map to rows in tables. So a given section of code may be juggling three arrays and repeatedly iterating (where did i put that one?) to find objects that relate to objects in each of the other arrays. This is obviously inefficient and very hard to read (especially when the objects passed around have fields that are overloaded, their values depending on the computation phase as they are passed around in a disgustingly procedural manner), so I proposed taming the colections with more intelligent, course-grained objects that would serve as indexes of sorts. Now, instead of looking through the array (or several) to find the sales for item X at store Y the code could just ask an object “get me the data for item X at store Y”. Even better if there’s some kind of normalization or reduction of the data, it can be done as the object is filled with the value objects. So this presents a perfect unit testing specimen, because I can fake up some value objects, toss them in and then test what comes out, with and without manipulation.

None of that is rocket science, but it does allow two things: significant complexity can be hidden and thoroughly tested without hooking it up to an app server (fixing something in a JUnit harness is much faster than redeploying to the app server), and secondly that the code to actually do the final calculations can be astonishingly easy to write, read and integrate into the application. Indeed, in this case, the code slipped into place with only one bug.

From the outside, it seems like a lot of extra work to mock out supporting objects and write tests, but having done it it I feel like it saved me several days of total development time. The end product is better too. I’m not sure I can get behind actually writing tests first, but writing tests (in parallel in my case) definately helps to crystalize my thinking about what my objects actually need to do.