Do One Thing

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. [Read More]

Trunk-based Development

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. [Read More]

Heirloom Code

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. [Read More]