The New Old Software

The forward march of technology is magnificent — sometimes the path to progress is so breathtaking that we lose track of just how far that path might stray from our everyday lives. It is great that Twitter and Facebook are inventing all kinds of ingenious innovations, but before we dive in we have to make sure we don't blot out previous generations of working software (and leave users high-and-dry). They (the kool kids) have different goals and requirements than we do…

This may not draw nearly the buzz and press of its Facebook-y counterparts, but we are seeing a terrific evolution in the processing of "legacy" software — a lot of great pieces are all coming together and developers are just catching on on to the combined wonder of them now. Here is the Hobbesian world of the-rest-of-software today:

• Vastly more brownfield than "greenfield" development — yes, the kool kids may be inventing Rails4.1.x and AngularJS and MongoDB, but we're NOT. We are more commonly asked to provide updates to current site, even if it was written all the way back in the bubble in ASP or JSP or something, with piles of HTML table-layouts and stored procedures.
• Outdated technology. A/JSP pages may have been great then, but they scream "2001: A Code Odyssey" now. There was nothing wrong with writing software that way back then, but we might do better now…
• No clear requirements, either for the legacy system or for the futuristic wonder that we are being asked to create to replace it
• No documentation of the legacy system,or libraries of documents that are ponderous and out-of-date
• Few tests or coverage of the legacy system, or…
• Bad tests — lovely unit tests that may all pass (if we don't touch anything), but might all break if we modify a single line of code...
• BUT (and this is critical) the current software mostly does work, and has lots of users who count on it!

We don't need kool-kid-ware, we just need the tools to advance in the world we live in. Most code stinks and simply disappears… The code that remains is still with us because it met a real need, with real users. Whatever sins may plague them, we're left with the winners and we need to take them boldly into the next generation.

We need the right approach, now — hesitation leads to even worse issues…

So here is our task — to skip the magical incantations (that might be great for Google-glass alpha-testers) and to mix a little magic into the systems that serve our customers and pay the bills every day. Here are the rules we will follow into that new world.

• Brownfield - we will evolve the code base, but we cannot break it and we'd be idiots to rewrite it!
• We will adopt leading technologies to provide new features — leading edge but not bleeding edge
• Our user base is engaged, but their requirements are sketchy — one of the most important creations from our work will be clear requirements for any future work!
• Our requirements and our tests will be read by future generations, but (face it) NOBODY is ever going to read our documentation, and we have no time or budget to write any
• Tests — TDD and BDD are a great step forward, so we will write tests AND we'll write them the right way, at the right level!
• We will update the system incrementally, and at every step in our updates everything will still work!

In my next post I'll describe how to write new old software, updated for 2014...