This is a mini-blog. I'm working to find a compromise between a tweet and a lengthy essay. I find it difficult to complete longer documents because of an obsession with perfection. So this little experiment is to see if I can create a blog of mini articles. Herein I will talk about many technical things generally related to software development and Agile practices.

19 July 2017

Scheduling Debt Payments

Over time all active projects accumulate debt to some degree. When development is most active the debt typically stays pretty low (unless you create the debt intentionally). Once a product is released to production however and maybe you aren't paying attention to its internals as much, it can start to fall behind the innovation curve. As you develop better solutions to common problems, faster techniques for building, or better ways to skin some cat or another, your 'old code' falls behind.It isn't reasonable to keep updating every single repository, although it would be great if you could. But some changes are necessary. That is, some innovations might require you to update every instance in existence. For example, a shared database API, or a build tool. So how do you get that done?Well, one simple thing you can do is schedule it. For example, declare that Friday afternoon is the time the whole team (or teams) stop and update all these things. If you aren't innovating that fast, do it every two weeks or a month. That is one effective an simple non-technological way to get it done.A better solution might be to create hard API boundaries on things and update packages. If you follow semver strictly this should be workable and give you a more automatic means of delivery. But this isn't always reasonable, it might be harder to make a package than it would be to make a change.Lastly, automation. The change is something like 'update the pinned dependency in the requirements.prod.txt file of all repositories', you should script that. Make it automatic and easy. Include in that all the necessary SCM changes. And if possible find a way to do mass PR approvals. This is especially true if the change is something you will do frequently.