Technical debt in a software system is introduced whenever you say “yes, I know I should do it that way, but I need this feature now so let’s do a quick-and-dirty thing and shoe-horn it into the system, and we’ll come back later and do it right”. Whenever you say that, and do that, then you introduce a technical debt into the system. You do something that takes a toll, and you owe it to the system to pay it back. Later.

You may think “this technical debt thing, that sounds interesting, how do I get one?”. Well, that part…


Time estimates, this little dance we do. I am not a fan of time estimates. Not at all. I avoid giving them if I can, because I have not come across many cases in my career where they have provided actual value. The only value that I feel come from time estimates is the deeper understanding of the feature at hand that comes from the discussion in the attempt to make the estimate. I often find the estimate itself rather useless.

Time estimates are in no way knowledge. They are guesses, at best. Any reasonable person, and most of us…


The feature request is ready for development. In your role as a solution architect, you get the question from the project requesting the feature to produce a ball-park-figure time estimate. Personally, I am not a big believer of time estimates, but that’s beside this story. As you read the documentation of the feature, you feel there are some things you need to clear out. There are questions to be asked. “After the user has done step 1, but before the system has processed it in process B, should the user be able to do any changes to the input?”. “What…

Fredrik Mörk

Software architect at Doro in Malmö, Sweden. Occasional speaker, photographer, and a nice guy, I hope.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store