Engineering Blog

Back in college, which wasn’t very long ago, I used to write code. Every program started the same, a blank Eclipse IDE window or blank text document. My assignments consisted exclusively of building functionality. As the semester trudged along the requested new functionality would become more complex, but it was always “add blah”, or “make it do bleh”. At the end of each semester, I would have a folder full of a few 1000-3000 line programs in a variety of languages. Every semester I would add another folder to my code inventory.

Things couldn’t be more different out in the real world. Since starting at Rally, I’ve been focused primarily on scalability issues, and in particular making our pop up editors stateless. Our old editors were very memory hungry, contributing to production issues. They were also sorely lacking concurrency handling. Holding state in the session also made it impossible to replicate sessions across VMs. Remember those non-serializable domain objects that Matt discussed in his last post?(See: Sessions across Nodes) The editors are largely responsible for placing them in the session. Not to mention that the code, which had been added incrementally over the years, was scattered and inconsistent. We had at least four different server side editor frameworks, and two on the front end.

Given this wide range of issues, we decided that it was time for an overhaul. This project actually started out similar to how all of my other projects did: writing new code. The Defect Suite editor was the first on the chopping block, we built a new stateless editor alongside our existing stateful editor, and hid it behind a feature toggle. Being mindful that we wanted to have all of the editors flow through one code path, we made a very generic high level controller to abstract out as much common behavior as possible.

As we made good progress on converting the editors, the time came to begin the cleanup effort. This is where my day to day programming experience really began to diverge from what I was accustomed to. Commit after commit, we were removing significant chunks of code. It became a common occurrence that hundreds of lines of complex logic would collapse neatly into our new framework. Any unique behavior was extracted from existing controllers, refactored to remove any extra cruft, and injected into our controller through the magic of Spring. I suddenly realized that I wasn’t really writing code anymore, I was compacting it.

Things really started to click for me around this time. The more widespread and longer term effects of our efforts started to become apparent. Out of this refactoring, fell the bonus of enhanced concurrency handling. I say it fell out because it was completely trivial to “add” to newly converted stateless editors. It came for free with the conversion. Implementing concurrency handling in the old system, editor by editor, would have never been feasible. The impact is truly much greater than just improved concurrency handling though. Any future change made across the editors can be done in one central, easy to read (see: Clean Code – Composed Methods), controller. Clean consolidated code is powerful stuff, it gives you the power to change directions rapidly and efficiently.

Working on the stateless editor project changed the way I thought about coding. A few years ago back in college, I would have never made such an effort to minimize duplication. My mentality was that adding more code to the system obviously improved it. I now see how duplication can easily make a code base unwieldy, and working on this project has given me the tools necessary to try and minimize it.