Modernize Your Legacy
Jay Hannah (@deafferret)
april 25th, 2014
Are you trying to bring modern development practices to a …less-than-modern software development environment?
Talk to any experienced programmer and they probably have a few stories to share about organizations that were — or still are — suffering from business, organizational, or technical practices causing unnecessary suffering for everyone involved.
“Why are they making this so hard?”
“If you’d just change X, everyone would be happier and more productive!”
Warning Signs
Maybe you’re unsure about whether your organization is behind the times. There are a few things you can check that provide pretty good indications that you may need to up your game.
Silos
One warning sign that you may be working in an unhealthy environment is a lack of communication between employees and across teams. If programmers have no idea what other programmers are working on, or how they’re working on it, then it is extremely likely that you’re dealing with a communication failure. Information silos are rarely healthy.
Which is not to say that every programmer has to know everything every other programmer is doing. Not at all. In a healthy environment programmers are happily churning out changes to software. They’re busy. They’re focused on their own work. That is good. But they can also tell you, in broad terms, what some other teams are working on. Shops that use an appropriate amount of cross-team code review can tell you lots of specifics about the code that others wrote this week. That’s great.
Visibility
Every programmer needs to be able to see everything that every other programmer has done on the project they’re both working on. When something strange happens, or some unexpected feature or bug is discovered that relates to the issue I’m working on, I need to be able to quickly see who last touched that area of the project. How, when, and why. I need to see both the code and the business problem (ideally recorded in the form of issues or tickets) which sparked the code changes.
Most programmers are now saying “Yes, of course. That’s called version control, and of course all programmers use it.”
Indeed. But it may surprise you that there are some very large, established development departments where the programmers and designers are still not using version control of any kind.
Some leaders view their environment like this: Give each programmer or administrator their own sandbox and list of responsibilities. Keep each of them specialized on their list of features, programs, systems, and tasks. In this way, when each new request comes into our organization, we know we can hand that to someone specific. Give that one to Bob. Bob wrote that part. Bob touched it last. Bob owns that.
Such specialization of technical resources may sound efficient, but it is a doomed strategy for long-term maintenance of any IT ecosystem of more than one developer. Only cross-trained teams can survive the inevitable loss of resources. Everyone retires eventually.
“We’re too busy for maintenance”
Managers afraid of deadlines may utter unfortunate lines like this. But experienced technologists understand the risks inherent in accumulating too much technical debt. When short-term, emergency thinking is allowed too much time to germinate it can take over the development philosophy of an entire team, and become the new normal. Over time progress and performance will grind to a halt as the code spaghetti and business logic inconsistencies multiply.
Good managers know that you can only operate in emergency mode for short bursts, and the long term consequences of poor development practices will eventually have a bottom line cost, in terms of both money and team morale. If you’re spending most of your time firefighting, you really need to stop and consider what might be making your software development environment so combustible in the first place.
“Houston, we have a problem”
If you recognized your own organization being described in any of the warning signs discussed above, don’t despair. There are two broad strategies, each with their own set of tactical actions, that can help you address your organization’s issues and modernize your software development practices.
Strategy One: Work Top Down
One option is to start by trying to convince leadership of the need to improve things. Some leaders will listen; some leaders will not.
All you can do is communicate clearly, calmly, and consistently. Offer concrete solutions to concrete problems that are happening right now and see if they’re willing to implement (or even open to discussing) change. Start small. See how they respond.
Political maneuvering is an art. You may find books like The Citizen Lobbyist helpful. Whether you’re lobbying your congressman for pothole money, or your boss to let you try the latest shiny framework, successful communication principles are the same.
Unfortunately, sometimes politics does not go well.
There are lots of reasons managers may not implement change. Many of them are social, not technical. You can only get to the bottom of those if you are willing and able to engage in political wrangling. Even then, that’s only if those doors are open to you and if you are inclined to walk through them. If not, you may want to put management discussions on hold and try some of the “Bottom Up” tactics discussed below. Revisit with management periodically after rounds of concrete progress have been deployed to production. Perhaps, with time, they will begin to listen to the people who are tangibly improving their environment.
Strategy Two: Work Bottom Up
If the “top down” approach isn’t an option, or didn’t work out for you, you can try some “bottom up” tactics. The key here is to only introduce new things when you can specifically quantity the improvement from the change. Once you get that first crack, continue to apply gentle pressure to expand the practice. Here are some approaches to consider:
Testing
Without structured testing, business people will constantly be stumbling into bugs introduced weeks or months earlier because the development and QA people responsible for changes were focused on whatever modification they were intentionally making, not the impressive list of unseen side-effects. Regressions must be fixed over and over again. Deja vu. Endless churn. Months and years tick by. Awful.
Testing to the rescue!
One nice feature of website development is that in a pinch you can test websites with zero access to, or modification of, the source code itself. By taking an entirely external, or “black box”, approach to website testing you can (perhaps) sidestep the politics of requesting changes or touching other people’s silos when they’re being territorial.
Tools like Test::WWW::Mechanize make it trivial to get started. And if Perl isn’t your tool of choice, that’s fine. Mechanize can hit any web server, regardless of what stack that server is written in (Java? .NET? Ruby?). And if you don’t want to use a Perl testing framework, use whatever you prefer. The important thing is to use something and get started! Today!
Test-driven development (TDD) tells us that step one in development is to write tests — tests for the previously delivered scenarios we knew about, and tests for any currently failing scenarios. Commit all that to git (or whatever version control system you prefer), and then iterate on the code until all known scenarios pass simultaneously. Commit again, and you’re all set.
Your test suite will snowball quickly, becoming an invaluable resource. In my case, those initial tests quickly doubled, then doubled again. All along the way I rely on my new testing framework to confirm that each new scenario raised by business or QA feedback is resolved without breaking any of my other (known) scenarios. Confidence and development speed skyrocket when you don’t have to spend countless hours clicking a website to verify that everything is working.
TDD is a less stressful way of life. If you haven’t tried it, please do. Your products, your business partners, your customers, and your loved ones will thank you.
Code reduction
It’s hard to argue against code reduction. If you can draw high-level diagrams of current and proposed infrastructure showing simplification opportunities you may be able to convince some entrenched interests that things can indeed improve. Try color-coding those diagrams: green for healthy infrastructure, yellow for things that need modification, and red for things that can be completely eliminated. Clear visual cues should be hard to ignore. No middle manager wants to get caught blocking progress which is clearly and succinctly visualized on a single page flow chart that her boss might see someday.
Profiling
If you don’t have performance metrics on your applications, the time to start gathering them is now! Extremely time sensitive organizations have this down to a science: Their continuous integration (CI) server (Bamboo or whatever you prefer) already runs their profiling benchmarks and compares them to previous builds, automatically rejecting builds which violate whatever performance tolerances they set.
But you don’t have to have a CI server in place to get started. Simple scripts which log to disk are a great start. Like testing, the most important step is the first one: if you’re not doing anything, get started today! Small and simple is infinitely superior to nothing.
Investing In Your Legacy
One other important thing to keep in mind — and something that can help with the political aspects of introducing some of these changes into a resistant environment — is that not only do they provide immediate measurable benefits, they’re also an investment. By putting forth some extra effort now, you’ll receive future dividends, in the form of more rapid development of higher quality software, with fewer failed projects.
I hope you have found some of these thoughts useful. If we can help you get started, or help you improve your existing systems we would love to hear from you. Or if you have specific topics you’d like to hear more detail on, please drop us a line. Thanks!