Development

I’m working for a client that has separate teams for architecture and engineering. Architecture is responsible for defining the long-term direction of the platform and engineering is responsible making that dream a reality, in addition to their day-to-day sprint work. Each engineering pod has a representative from architecture as one of its members but their role is mostly about producing documents and interfacing between the two teams - they don’t touch the code at all.

One thing that development teams constantly struggle with is striking a balance between building features, fixing bugs, paying down tech debt, and embarking on more ambitious activities like replacing core components in their architecture. It’s also something that Agile tries to solve but I’ve never seen it solved to everyone’s satisfaction.

And I think it’s because many Agile Product Owners are focused on the specifics of what features they’d like to see built instead of setting the direction for the dev team and letting them figure out how to get there. They allocate some random percentage of the sprint to tech debt just to keep the team happy but it’s hard to make significant changes with 10% of the sprint capacity.

Software should do one thing, and do it well. Each piece of software should have a clearly-stated goal that is used to determine whether a particular feature should be implemented or not. When a proposed feature does not fit with the software’s stated goal then don’t implemented it. Just don’t.

Like adding source control to your product. We already have several perfectly good source control systems. Building your own custom source control system into your product is never a good idea. Your implementation is unlikely to be as good as the standalone products like Git, Mercurial or Subversion, and it’ll probably make it difficult for me to use my source control system of choice.

I’ve been working on re-platforming the online banking system for a Canadian retail bank for over two years. Leading up to the initial launch, The Business decided to defer a few features to the next release which was scheduled for about a month later. We created a release branch to support defect fixes found in testing, and the development team continued adding features to the develop branch. Bug fixes from release were merged into develop regularly. The process was working.

Michael Feathers says that legacy code is any code without tests but I’d go a step further and say that legacy code is any code that is still running even though the original developer(s) are no longer working on it. And there is certainly plenty of that in financial institutions. There are other characteristics too, such as:

• unreproducible production environment
• incomplete source control
  • missing files
  • ‘master’ fails to build
• no automated build process
• no release process
• few or no unit tests
• no way to run or test the code on a developer workstation
• little or no documentation
• none of the original developers available

I am presently working on a codebase that checks all of the above boxes and it isn’t even that old but instead of dismissing it as an unmaintainable mess I have changed my mindset and have started referring to it as Heirloom Code.