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
This is less of an issue for the freelancers out there (I guess you could deliver your code and then just disappear, but I don’t really think this is a good business model). For the full-time people out there though, you’re going to have to support the code you write. In the short term, this may not seem like an issue since your approach is fresh in your mind. In the medium to long term, however, inevitably you’ll have to revisit this project again whether to add new features or debug an issue. A year from now, are you still going to remember how this all works?
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
No one wants to work on poorly written hacky code. The other engineers around you will do whatever they can to avoid working with you, and anyone who does will eventually burn out due to out-of-control technical debt. In general, just doing the bare minimum to make things work, and hopping from problem to problem leads to your team accruing a lot of technical debt.
Once other developers start working on your code one of two things ends up happening:
- 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.
- 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.
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 a situation where new developers brought into your team need to be hand-held through everything. They’re unable to make assumptions about the project 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 leads to a situation where you always need to be available to answer questions about the project. I’ve seen situations where things have gone so far off the rails that you can’t even follow the underlying framework documentation anymore because of how customized things are.
It stymies innovation
Engineering is a constantly evolving profession. Just because the technology your company chose 20 years ago was the best choice at the time does not mean that it still is. The whole concept of plugging away just focusing on solving the problem in the quickest easiest way is the exact opposite of what you hire engineers for. 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. While yes, you can’t always rewrite everything and you need to balance the business needs, you should still be looking for ways to improve and make the project better.
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
You can only put off the inevitable for so long, eventually, the technical debt becomes too insurmountable and you’ll be forced to start over. Hopefully, by this point, you’ve learned a lesson and have started to do things in a better way, but I’ve seen time and time again companies repeat this same cycle over and over.
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
As with all things the solution is balance and consistency. Do you need to spend months thinking about the best folder structure or variable names, for your application? Probably not, but do these things at least warrant SOME thought? They definitely do! Don’t go overboard with it but save yourself the headache down the road. Enforcing 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, 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”.
