Use the simplest thing that can possibly work
“Whether you are designing systems or individual modules, never forget to use the simplest thing that can possibly work.” — Robert C. Martin
I found this quote on Twitter the other day and it really resonated with me because working as a Front-end Developer with new preprocessors, task runners, version control and other general tools being shoved in in my face all the time that so called ‘make workflow more efficient for the developer/developers’ are tempting to implement but in this article the question I want to approach is DO YOU NEED IT?
Just to be clear here I am talking about asking the question of IS IT NEEDED? To not just in the code you write but also right down to the platform chosen for any given project and the decisions made throughout the duration of the project timeline to ensure anything not needed either does not enter the project in the first place or is abolished before it causes any issues and confusion.
Just because you can doesn’t mean you should
Like it says in the quote that sparked the idea for this article ‘use the simplest thing that can possibly work.’ don’t just use it because a trend setter in the industry finds it useful or because they recommend it, instead try to base what you use on your specific use case versus someone else’s. Use it because you genially see a true advantage and use case for it.
Implementing a particular platform, framework, method or tool to a project to make it simpler could do the opposite and cause more cognitive overhead.
For example I have worked on projects for companies that use the Wordpress platform for a single page site that doesn’t require the client to be able to edit the content and media (Wordpress is handy when used in the right circumstance).
Developers now have to put quite a lot of effort into the additional setup, performance and security issues that come with going with the Wordpress platform for no real advantage or no benefit at all seen as the key features that Wordpress brings aren’t and won’t be used and all this is because the platform hasn’t been chosen for the use case. So this just causes an unnecessary headache for the developers setup and to maintain the site.
Keep it simple
I think it is important to weight up the trade off’s when considering adding more complexity to a workflow or codebase just because you can, it’s really tempting to just add that extra bit of complexity to a project to solve a particular problem that may be occurring.
This can create an unnecessary convoluted codebase. The amount of codebases I have seen when going to do work for various companies that use a task runner like Gulp with way to many functions to do one task or a variable contained within another variable, it just starts getting hard to follow at that point. I understand what they are doing which is breaking down there logic into more digestible chunks so it is easier for the developer to read but if you go too far it actually ends up been harder to read.
I also think part of the problem is that we are often told by the employer or client we need to support this and that and supporting all the browsers under the sun as well as all iterations of those browsers, it just get’s a bit over the top in some cases. For an example of a tool that keeps things simple for the developer is autoprefixer as it automatically includes the necessary vender prefixers into your css for you.
Plan from the start
I think a crucial time to decide whether or not to use something whatever it is SASS, LESS, GULP or platforms like Wordpress, Processwire and Magento is before the project has begun because a solid foundation is key to the success of any project.
So decide early on starting with the type of project structure and technologies to include such as which preprocessor to use or none at all and then decide a methodology to follow such as OOCSS or BEM and take it from there.
SIDE NOTE: Ensure if you are working on a project with other developers you are all agreed on the technologies chosen and informed and understand the best way to instigate them.
Now I am not saying here don’t add any complicity at all. Using a MVC such as Opencart it is inevitable that stuff is going to get complex with a large verity of languages and tools being used but knowing that as a developer you should try and not add even more convoluted aspects to the project, the aim should always be to at least not add to an already overly complex codebase if you can reduce the entanglement.
In fact in most cases implementing a complex solution wether it be a platform or line of code that may seem ‘hacky’ to solve a particular problem is what is needed however don’t just assume that a complex fix is the only choice, look around for a less convoluted and simple one before assuming a more complex fix is the only option or the best option.