You know that feeling when you can not decide whether to refactor more or if it's enough refactoring? That is pretty much how I feel when I am writing web apps. Some days I am working on every little thing—modular code, unit/feature testing, and adding detailed documentation, among other things. Sometimes I feel like saying, "Eh, I will just throw this together and hope it works." Over-engineering and under-engineering are always at odds with each other. Really, both are good in some situations, but how do you know when to use which? That is the tricky part.
To begin, let us talk about over-engineering. Imagine that you are building a house, but instead of just putting in the basics, you are adding hidden rooms, extra insulation, appliance automation (those app controlled devices), and endless outlets that no one will ever need. It is kind of like that when you over-engineer things in software development. You are not just writing code; you are making this masterpiece that is well organized and easy to maintain (cross finger, haha). The code is well-written, scalable, and adaptable, and it has error handling and safety features that any developer would be proud of.
Over-engineering is a way for me to protect against the future. The structure and documentation will help me quickly figure out what went wrong if it does happen (trust me, it always does). Also, if the app suddenly gets bigger, I will not have to start over—it is ready for scalability. Using design patterns also makes it easier to fix bugs and add new features. Very easy to extend.
It does take time to over engineer, though. It feels like I am building a skyscraper when all I needed was a simple one-story house at times. I have caught myself adding extra features and ways to handle edge cases to a project that, in all honesty, no one will ever use at the moment. You would spend all night making the perfect meal for a dinner party, only to find that no one is really hungry. Yes, it is impressive, but do we really need it?
Now let us talk about under-engineering. This is how I feel when I just want to get something done quickly. There is a lot of pressure, and I do not have time to design and architect a project too much. I am going to skip the edge cases and just hope everything works out. Fast and effective, and good for a quick project or MVP. Many times, I have done this, especially when I just need to get something done.
Not doing enough engineering can, of course, backfire. Shortcuts and quick fixes? They keep piling up. All of a sudden, I see a bunch of code that is not organized and is hard to keep up with extendability and maintainability. I feel bad that I did not put in a little planning in the beginning because now I have a lot of technical debt.
Where is the balance then? To be honest, it depends. If you want to make something last a long time and be maintained, over-engineering is the way to go. But for small things or things that your boss wants to get in an instant? Under-engineering can help you save time and hit those deadlines. It is all about finding the right balance. There are pros and cons to both of the choices you make.
It is important to know when to go all in and when to keep things simple. Finding balance is another skill that you'll unlock as you go deeper and gain more experience in software development.