“Just make it work” is a dangerous mindset.
By: Andrew T.
Tags: Engineering, Code, Software, Software Development

Over the past few weeks, I’ve started noticing a lot of posts and memes about the “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 say that “wasting” (in their mind) time on things such as structure, architecture, framework/language choice, etc. Isn’t worth the effort and instead we should focus all our efforts on just solving the problem in front of us as quickly as possible using whatever tools just happen to be strewn around the room at any given moment.

While I do agree that in the end the customer usually doesn’t care about how you solved their problem, I could go off on a whole other tangent about why this is also a huge problem, but for now, let's stay focused shall we? This mindset is toxic for many reasons, I’ll elaborate on a couple of them here but there are certainly more.

You’re going to have to support it

This is less of an issue for the freelancers out there (I guess you could just refuse to work on the project ever again after you’ve done your damage, but that’s not exactly a great business model). For the full-time people out there though, you’re going to have to support the code you write. What happens down the road when a new feature request comes down the pipe that’s simply not possible because of the scatter-shot approach taken initially?

In my experience, I’ve been forced to deal with others taking this approach and it never turns out well. You’ll look great upfront because you delivered a feature ahead of schedule and sure, it does exactly what the stakeholders need… at least right now it does. What about next week, next month, next year? How is this feature going to evolve? Are you certain that the stakeholders will never ask for a modification to this feature ever again? What about if someone finds a bug, will you even remember how this works later, or are you going to have to spend hours/days refamiliarizing yourself with your own code to debug a simple issue?

But who am I kidding, let’s be honest, the people who do this always end up doing the same thing: They write their hacky, careless code. They get praise for getting things done ahead of schedule. Some time passes and a new feature request comes in. The original developer now either ignores the feature request entirely, is all of a sudden “too busy” to take this on, or has left the company to wreak havoc elsewhere.

Regardless, now the code is someone else’s problem. Which brings me to my next point.

Your co-workers are going to hate you

The real engineers around you know better than to get involved with these kinds of bad practices, they’ll do everything in their power to either avoid working with you or just leave the company entirely. Anyone who manages to be coerced into staying eventually burns out due to out of control technical debt, stress, and constantly running on the hamster wheel working on the same features all the time and never adding anything new.

Over time these types of “just make it work” engineers end up in their own little sandbox because no one wants to play with them anymore. This eventually causes more damage though because you now have a wild-card in your organization doing whatever they want without an adult to reign in their bad choices. This leads to code living in your organization which no one but the one hack developer understands.

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

They determine that code is too much of a mess and needs to be totally rewritten and replaced, a hard sell in any organization, but especially bad in places where you’ve been down this road several times before. They adopt the (possibly 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 that’s raging in your organization.

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

Standards and best practices exist for a reason. Just deciding to do things “your way” because it’s easier, or worse, “you think you know better” leads to situations where new developers brought into your tangled web of code need to be hand-held through everything. They’re unable to make assumptions about your code because you’ve gone off on a tangent just hacking things together with no regard for anyone else around you. This leads to unnecessarily long training time, and also requires that you need to be the one who does the training. “Just make it work” is cancer in our industry, having the cause of this cancer training the next wave of engineers is just furthering the spread.

It stymies innovation

Engineering is a constantly evolving profession. Just because the technology your company chose 17 years ago was the best choice at the time does not mean that it still is. The whole concept of “just use what’s in front of you” that goes hand-in-hand with the “make it work” ideology is the exact opposite of what you hire engineers to do. Engineers should always be looking for better ways to do things, better patterns, better practices, cleaner structure, performance improvements, etc. This is the difference between an Engineer and a Programmer. Engineers are focused on the how and why of a problem they determine the best way to solve the problem and relay that information to the programmers to write.

Engineers don’t do well in environments where they don’t have to think. Solving problems is our bread and butter, taking that away by perpetuating the idea that all that matters is making things work and just always choosing the path of least resistance removes all of the joy from programming. You can argue that an employer/stakeholder likely also doesn’t care about how “fun” the job is, but at the risk of burning out your talented engineers and driving them elsewhere, you may want to consider whether or not your engineers actually enjoy their jobs.

In the long run, it hurts your customer

You can only put off the inevitable for so long, eventually, the technical debt becomes too insurmountable and you’ll be forced to rewrite everything. Hopefully, by this point, you’ve learned a lesson and have started to do things right but maybe not, maybe you’re a glutton for punishment and you’ll just repeat this same cycle all over again. The point is when you get to this phase you’re now at the point where your customer is going to ask for a simple change and because of seemingly random dependencies on totally unrelated chunks of code, you’re going to realize that this task which should take a total of 5 minutes is going to take you a weeks/months in the current cobbled together architecture.

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 by jumping from one “just make it work” feature to the next. Over time even updating text on a page 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 most minor of changes.

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 written 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, or maybe you can kick the can down the road a little further by adding “just one more hack”.

The Solution: Balance and Consistency

As with all things the solution is balance and consistency. Do you need to spend months thinking about the best folder structure for your application, variable names, probably not? But do these things at least warrant SOME forethought, I argue that they definitely do. Don’t go overboard with it but save yourself the headache down the road. Enforcing these standards and best practices across your organization also keep everyone on the same page, simplifies training and ramp-up, and keeps the team accountable.

Any well-written software project benefits from a well-defined structure, keep things flexible and let the project grow naturally. 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”.