|
Ask several programmers and managers, “What's legacy
code?” and you'll get different answers. Common answers
include “code that's hard to work with”, “code lacking
automated test coverage”, and “I know it when I see it.”
Everybody would agree, though, that they don't like
legacy code. It makes system maintenance and extension
harder. Programming around legacy code is scary, because
you don't know what you break. It invalidates estimates
for new development. Such code might well be an asset to
your organization, but it weighs ever more on the
liability side of the ledger.
Now let's say your team has adopted Agile. You're
developing code in decreasing order of value and risk.
You allow changes to the requirements. Team members are
welcome to work anywhere in the codebase, even where they
are not experts.
Are you comfortable with this approach? If you believe
that solid code can only result from experts working from detailed
specs and designs, this agile approach might look like a
disaster waiting to happen.
In fact, in many Agile shops that's exactly the case.
Some folks mistakenly believe that by calling themselves
agile, they don't need to do design anymore. Others see
the iterations as tight deadlines that force them to
forgo design. Project schedules are always tight and
“aggressive”, so there's never time to go back and
improve design. In short, those folks still produce
legacy code, only faster.
Some Agile teams counter this tendency by still doing
architecture and design the old way: before any code
is written. They have to know most of the system's
contents ahead of time, and they account for everything.
This approach stifles change and protracts schedules. I
could tell you many stories about that, but I'm sure you
have your own.
Agile teams have one overarching purpose: Deliver
customer value. That purpose has a secondary clause: “Do
so while setting up for delivering value in the next
round.” In other words, they write their code now so as
not to mortgage their future ability to write further
code. This does not mean making the code so generic it
can handle every eventuality; it does mean making it
simple and pliable so it can be adapted at low cost.
This is where the approach of doing architecture and
design ahead of time breaks down. It might solve this
project's needs (while stifling change and protracting
schedules), but it certainly doesn't help the team to set
up for the next project.
Empirical proof of this is everywhere. If you've ever
“re-architected” a system (that's usually around version
3 or 4), or worked on a system that included two or three
frameworks that have the same purpose, you'd know
first-hand how helpful early designs were.
So, what's the solution? How to avoid producing instant
legacy code?
The answer is to integrate an appropriate technical
discipline. Just like the Agile framework for project
management, this technical discipline is built around
evolution and small, safe steps. Specifically:
- When you're working on a small iteration story, write
simple, minimal code. Make sure its design sits well with
existing architecture, or even furthers it. That's TDD
(test-driven development) with continuous refactoring.
- When you need to keep developing but the design “gets
stuck” (doesn't readily support the next addition), adapt
the design before proceeding. That's again refactoring.
- Break down your work into small steps. And then break
them down into even smaller steps, so you're not tempted
to do Big Design.
- Automated Low-level tests are your friends. Have plenty
of friends (even if some are being difficult), and take
good care of them.
- Get quick feedback from your code, team, users, and
environment. Don't sit on that feedback; apply it
forthwith, including making required design improvements.
- If you find yourself producing instant legacy code —
cryptic, spaghetti, don't-touch-it, the kind you won't
understand next month — STOP. Step away from that code!
Think carefully, and correct it NOW. Don't wait to pay
for its shortcomings when you can least afford to.
These technical disciplines imply that you're not just
developing every day; you're investing in your code
every day. That's how you curtail technical debt and
prevent your asset — your code — from turning into a
liability.
Copyright © 2011, 3P Vantage, Inc. All rights reserved.
|