“Just make it work” is a dangerous mindset.


Recently I’ve been seeing more posts about this “just make it work” mindset, and how in the end “the customer doesn’t actually care if your app is written in PHP or the newest, shiniest framework”. They go on to claim that “wasting” time on things such as structure, architecture, framework, and language choice isn’t worth the time or effort and instead we should focus all our efforts on just solving the problem at hand as quickly as possible using whatever tools just happen to be in front of your at that moment. While I do agree that in the end the customer usually doesn’t care how you solved their problem. This mindset is toxic and destructive for many reasons, I’ll explore a couple here but there are certainly more.

You’re going to have to support it

Initially, you’ll look great for delivering features ahead of schedule, and sure, (for now) it does exactly what the stakeholders were looking for. What about next week, next month, or next year? How is this feature going to evolve? Are you certain that this feature is final and will never have to change again? If a change is requested, will you even remember how this works, or are you going to have to waste hours or days trying to refamiliarize yourself with the code?

Your co-workers are going to hate you

Once other developers start working on your code one of two things ends up happening:

  1. They determine that code is too far gone and needs to be totally rewritten, a hard sell in any organization, but especially bad in places where you’ve been down this road several times before.
  2. They adopt the (even worse mindset) “I’ll just use this one little hack here” to get things done. Thus adding more fuel to the technical debt inferno.

You exponentially increase ramp-up & training time for new hires.

It stymies innovation

Engineers don’t do well in environments where they don’t have to think. Perpetuating the idea that the only thing that matters is getting things working using the path of least resistance removes all of the joy from programming. You can argue that an employer/stakeholder doesn’t care about how “fun” the job is, but at the risk of burning out your engineers, you may want to spend some time ensuring people enjoy working for you.

In the long run, it hurts your customer

A great example from one that’s permanently etched into my mind is of an engineer who decided that they knew better than all the accepted standards and practices out there for a particular framework. This engineer cobbled together such a tightly coupled architecture. Over time even making minor business rule changes to a simple API call was problematic without touching multiple files and making major sweeping changes to the entire overall application. This lead to our QA team being forced to test seemingly unrelated features across parts of the application which had nothing to do with each other for even the smallest of changes, as well as huge diffs in pull requests.

In the long run, all this mindset does is delay the inevitable. Eventually, you will have to think about structure, architecture, language choice, etc. The problem is you’re now thinking about this at the worst possible time, with your customer breathing down your neck because you’ve set the expectation that you can do anything quickly, and when you already have a mostly finished product. As you start to peel back the layers and dependencies, you’ll start to realize more and more of it needs to be rewritten/refactored until you eventually come to terms with the fact that you need to start over.

The Solution: Balance and Consistency

Any well-written software project benefits from a well-defined structure, keep things flexible, and let the project grow naturally, but also be sure that you’re always leaving things in a better condition than you found it. Spend time keeping up to date with best practices, learn new tools and frameworks, and where their strengths and weaknesses are. Use the right tool for the job at the right time. Don’t force a tool that is a bad fit to work just because “it’s what’s there”. As always follow the golden rule of software development: “Always assume that the next person to touch your code will be a murderous sociopath who knows where you live”.

Staff Software Engineer @ Wayfair https://github.com/andytavares Opinions expressed are solely my own and do not express the views or opinions of my employer.

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