I do it all the time. And it is hard not to sometimes when you get into the flow and you keep thinking of cool new feature after cool new feature to add to your projects and you can't stop from typing away.
There's a good chance that the future you will regret having done that as they wade through hundreds of lines of code that kind of make sense but that didn't really help you get that project completed.
So first off, what is over-engineering?
Coding too much?
Over-engineering, as the name implies, is simply building more than is required in order to finish a project. If for example, I asked you to build a simple calendar widget that let a user select a date and that was it, and you came back with a fully-optimized NPM ready calendar module that's API driven with fancy animations and usable until the year 30,000, you could consider that to be over-engineered.
It's not wrong, it's just that no one really asked for it, it probably took longer than needed, and there's more than likely a substantial amount of code that went into it.
In fact, much of the work that I do on it now involved removing or refactoring the code so that it isn't cumbersome and the chances for error are reduced as much as possible. Here's a few of the things that I've begun to do in order to reduce over-engineering as much as possible and that you should consider in your own projects.
Determine an MVP
The MVP (or Minimum Viable Product) is a startup term, but essentially it refers to the minimum amount of work that can be done to get a fully-functioning product out to market. Minimum is the keyword here.
It's a startup term, but you can use it with any of your coding projects as well. Before you even start, have in mind what you want your MVP to be and then code just that. Odds are you are going to get many other ideas as you progress. That's fine. Write those down as Phase II items and keep going.
I assure you, as soon as you launch your Phase I, most of the items that you wrote down for Phase II probably won't make sense anymore. Which is why I say write it down and sleep on it.
I personally spent about 3 weeks building out a complex folder system for my content that was difficult to build, fun to build and a pain to maintain now. And I almost never use it. Pretty much every article I write goes into the 'Articles' folder and that's it.
But because I was already making changes to the category system, I kept going pretty much. And now, I can't really undo the work without having to tear everything down.
Truthfully, I actually enjoy the folder system. It's useful. It's just that I don't really have a use for it right now on this blog personally.
This is the best way to prevent yourself from getting carried away. Sometimes the best ideas in your head that are super exciting and that you can't wait to build are terrible, and nobody wants them.
Again, welcome to my world. I have ideas all day long and because I've been at this coding thing for a while now, I can usually get most of those ideas out in a few days. Except much of the time, I'm just building things based on my boredom and nobody asked for them.
Again, not wrong. You can code whatever you like if it's your hobby or personal project. If you are working for a company though, you should probably stick to the script.
And the best way to do that, is to have someone look at it and tell you what they think. This does two things. The first thing, is that at least for a short while, it will stop you from coding. And the second thing, is that there's a good chance the person looking at it won't be as impressed as you are. That's not necessarily a bad thing. This could demotivate you just long enough to prevent any excess coding to take place.
I've been humbled many times during my professional career in this regard. When lead developers do a code-review, they tend to focus on the requirements only and are not really impressed with any added functionality. And that's because any senior developer has learned the ropes and knows that following specifications is key to having a good product launch.
Don't forget, you can always come back and add this feature that you have in mind later. But it's almost always better to only do it when it really does make sense to have or when there is some kind of demand for it. Any other time and you are probably just doing it for entertainment purposes.
Use a task manager
You should be doing this anyway. But breaking down your project into as many steps as possible before you even start is a good way to ensure that you stay on course and that you do so in a timely manner.
I personally use Trello for much of my task management, mainly because it's free but also because it was built by Joel Spolsky and I'm a fan of his work (aka StackOverflow).
Any new task that I have, I create a task list for it and create a card for every item in that task. If I'm building a landing page for example, that typically involves creating the hero section, the feature section, some form of email capture and ensuring that it is responsive. And that's it. That's the MVP and that's the task list. I'm not going to be refactoring the website or coming up with a fancy new way to load CSS.
The Trello board keeps me accountable to those items and those items only. Sometimes having that visual queue really can make the difference in what you end up building.
So whenever I get that anxious feeling that I'm probably over-thinking things, then these days I tend to listen to it and I sleep on it. But I write every idea down no matter what. Because today might be the wrong time for this feature, but 3 months from now, it might make all the sense in the world.
Walter Guevara is a software engineer, startup founder and currently teaches programming for a coding bootcamp. He is currently building things that don't yet exist.