If developers continue to face pressure, and are forced to take shortcuts because a business decision was made, over time that behavior becomes the normal. It’s hard for someone to maintain quality when they’re constantly beat into taking shortcuts, when they find time to focus on quality, their mindset has already shifted and it becomes very difficult to adjust, if not impossible to do it without influence.

Unless someone is enabling developers to focus on quality while taking shortcuts (I’ve rarely observed proper enabling), then the developer will conform to the direction the pressure forces.

If you already have a good culture, decent process, good practices… then being faced with the analogy above, sure, it should be a no brainer. Take the shortcut, come back and get it fixed, it’s rarely that simple at scale (and requires that the customer wants to come back and get it fixed).

Me, car owner – PO/Client
Car – product
Mechanic – dev team.

And the reason it doesn’t hold up is that the roles you have in your analogy are totally mixed up. Good fodder for another post though maybe you understand the mixup now that it’s been pointed out?

> That’s an example of “business” driven decision about the quality of product.

No, that’s an analogy.

That’s an example of “business” driven decision about the quality of product. In the end, it’s your property, if you want it working it NOW taking responsibility of shortcommings, it’s ok.

Viktoras, it’s not a matter of “crap or full-featured framework.” It’s a matter of “can I live with this for the foreseeable future.” This is significantly different from “I will do something in a sloppy/wrong way and plan on changing it in the future.” The decision making about technical things is in the hands of the programmer. For example (I’ll make this a full blog post in the future), we needed to put up a warning banner in our site, for example if our email provider is having an outage (see my last blog post). There are many ways to do this. We decided on a static file we serve from our marketing site. This isn’t a gold-plated solution (something controllable by our administrative app, or another 3rd party service). Nor is it a hack job (editing source files and doing a deploy). It’s something I would have no trouble living with until it becomes a priority to expand capabilities. And it was done in a deliberate, responsible way. I don’t call that technical debt, I call it a good solution.

I completely agree, pay the price upfront for complete solutions. Now that being said sometimes you don’t get the time you need to do it right, you are hamstrung by the fact that if you don’t get the system going enough to get you over the line you could end up not having a job to complete. This is a tough balance, but as soon as you have some stability and reserve double down on fixing it.

…you should take that shortcut.

If you can hardcode configuration for first deployments, do you really need that config file support?
If you have a weird production issue, do you have time to investigate, or a silly hack (periodic server restart, limit number of concurrent users, increase timeouts) will do for the time being?
Do you really want to create a full-featured framework before putting that requested feature on top of it, or can you somehow hack the feature up from semi-made pieces, it will not be reusable for other similar features, but at least you can start getting some feedback on this, and only THEN shape some sort of a proper framework?

Yes, most often you would want to choose a proper path straight away, but you don’t always have a luxury, or even the need for that.

Tech debt is not about “sloppy”, or “bug”, “poor quality”. Tech debt is about “shortcut”, “workaround”, “temporary fix”, “hack”. It is actually useful to know when you can use one of those.