Freek.dev

This week I wrote about my experiences with technical and architectural debt. When I was a developer we used to distinguish between code debt (temporary hacks) and architectural debt (structural decisions that bite you later). But in enterprise architecture, it goes way beyond technical implementation.

To me architectural debt is found on all layers.

Application/Infrastructure layer: This is about integration patterns, system overlap, and vendor lock-in. Not the code itself, but how applications interact with each other. Debt here directly hits operations through increased costs and slower delivery.

Business layer: This covers ownership, stewardship, and process documentation. When business processes are outdated or phantom processes exist, people work under wrong assumptions. Projects start on the back foot before they even begin. Issues here multiply operational problems.

Strategy layer: The most damaging level. If your business capability maps are outdated or misaligned, you're basing 3-5 year strategies on wrong assumptions. This blocks transformation and can make bad long-term strategy look appealing.

Read more [frederickvanbrabant.com]

Technical debt is not simply a measure of the specific work needed to repay the debt; it is the additional time and effort added to all past, present, and future work that comes from having the debt in the first place.

Read more [www.oreilly.com]

Mattias Verraes explains a method for making technical debt visible and negotiable.

Read more [verraes.net]

Harry Roberts makes the case for making technical debt visible instead of trying to hide it.

This means that, although far from ideal, the impact of these hacks is well contained and signposted, meaning that they won’t slip through the cracks and remain hidden in the codebase for the next five years.

This pragmatism and lack of stubbornness can make your codebase much more malleable, resilient, and ultimately much more useful. Everything is a compromise.

https://csswizardry.com/2017/10/airplanes-and-ashtrays/

Read more

In a new post on his blog, my favorite stalwart of the industry Frederick Vanbrabant, gives a explanation on why some projects turn into a big mess and how you can avoid it.

I truly believe that the broken window theory can be applied to software projects. In my personal experiences I’ve rarely seen a project start out as a total mess. If it ended up as a mess, it was gradually. I also believe that this is not necessary the fault of developers working on the project, think of it more as frogs in a pot with gradually increased temperature of water. One morning you just wake up and take a look at the project and realise that it has gotten really messy.

http://frederickvanbrabant.com/2017/06/12/broken-windows-theory.html

Read more

Fred Hébert on his blog:

... sooner or later, people start misinterpreting the original intent and thinking of technical debt the same way you could think about financial debt: a lever to use in order to get something now and then pay the accrued cost progressively over time. This is however not how things feel from the technical person's point of view. ... Rather than focusing on why that is wrong, I want to propose an alternative analogy to describe the reality behind technical debt.

http://ferd.ca/on-technical-debt-shoveling-forward.html

Read more

Bill Jordan wrote an absolutely amazing piece on the things he learned in the twenty-eight years he worked in the software industry. There are so many good insights that I can nearly quote the entire article.

Here are some of the things that resonated with me:

Odds are far better than good that your high performers are achieving what appears to be high levels of productivity by building technical debt into the application by taking shortcuts whether intentionally or unintentionally. These kinds of high performers are actually low performers when when TCO is factored in.

Encourage developers to improve the application while working on their projects. Examples of improvements are creating reusable objects out of copypasta code and breaking up large objects that are difficult to maintain into smaller objects that individually are easier to reason about. Improve the database schema even if it hurts in the short term. Delete old and unused code. With the benefit of hindsight update the user interface to improve user experience — sometimes even just changing a word or two makes a big difference.

When continual improvement is part of the DNA of your team you’ll be amazed with the results, but give those results some time to become apparent — it won’t happen overnight. It also means management will need to recognize that things will take more time since developers will be working on their primary project while simultaneously making incremental improvements.

Be sure to read the entire post: https://medium.com/@billjordan1/the-quiet-crisis-unfolding-in-software-development-cffbdafbf450#.1j7a7qos3

Read more

Jeroen Moens posted a, very well written, article on paying technical debt in a legacy codebase.

How can you get a legacy codebase under control and bring it to a new level of maturity? This post summarises my advice and lessons learned from years of working on a large legacy web application.

On a sidenote: as an Artisan I always like to sneak in a little Laravel in legacy projects. There are a lot of Illuminate components take can be used independently outside Laravel. If you want to do this too take a look at Matt Stauffer's Torch repo on GitHub.

Read more