Being Done Now With Tech Debt is Better Than Being Late Forever

So I have something I call the “Pragmatic Overlay”. Its the concept that you can have an idealized vision or plan for whatever you are wanting to do. But, and this usually only comes based on experience, you have to have an element of pragmatism to it. Some simple examples are “I want to go to the beach” so “I’ll need to vacuum my car the next day because it will be full of sand”. Or “this will take 5 working days” but “in reality you know it will take 7 because we are relying on an external vendor and they are usually late”. Things like that.

So here is a lesson I’ve learned using my pragmatic overlay.

“Being done with tech debt is better than not done with a plan for perfection that takes forever.”

This frequently shows up in second-system effect. Developers are given a sprint task to implement a user story. They then take something that could be written fairly quickly, say a week, and it ends up taking 5 weeks because they are trying to implement all sorts of extra features. I get that some things are valuable, like adding logging and debugging features. But I frequently see developers making something extra complicated because they are trying to “future-proof” it.

Here’s a common example. We need to take csv file A and jam it into database fields B. Instead of just finding an open-source library, or just making a simple stored INSERT procedure, the developer starts to build a fancy backend system trying to store mappings of various potential csv columns to field names, “just in case”. Sometimes this even results in creating all new db tables to manage this new feature.

Meanwhile, the development timeline drags on and the users with the existing csv files are sitting around waiting for their app.

In my experience and opinion, it is better to just get the existing feature request released, even if it means just hardcoding the parsing and field mapping. Those users are waiting and your business or organization is losing value. Now that doesn’t mean you can’t author a user story for a feature to “create an automated way to parse future csv files and map to database tables and fields”. But you need to focus on the user next step and make sure you don’t get caught up in worrying about next year instead of right now.

Leave a comment