There’s a quote often attributed to Albert Einstein that I quite like (and I’m sure most do):
Everything should be made as simple as possible, but no simpler.
There is some investigation as to if he said it or not, but the point remains regardless of who said it.
It’s easy to take this idea and apply it to things that we do in everyday life that we don’t want to do, right?
- I don’t want to clean my room, so I’ll tidy it up just enough.
- I’ll do just enough work to satisfy the clients, and that’s enough.
- I’ll fulfill the to and because Einstein said it, who am I to argue.
Even though I don’t agree with it (and the discussion for that is outside the scope of this post), I do consider this idea within the context of web development.
And to be clear, I’m not talking about web design. I’m not a designer. I don’t want to speak on behalf of something of which I’m not a part. But regarding providing solutions for people using software or, rather, web development, I’m far more inclined and positioned to talk about this.
Strictly speaking, I find myself often wondering if we’ve made web development more complicated (and why we’ve done so) and if using the simplest thing that’s needed is all that’s really needed when building solutions for others.
The Simplest Thing That’s Needed
I’ve recently written about the various aspects of front-end development alone (within the context of getting something out of the door quickly) and how we now have build tools strictly for that aspect of the web development stack.
When it comes to tools like this regardless of which level of the stack on which we’re working, I find myself asking:
Is this utility necessary for effectively, and positively making it easier to develop the solution for someone else?
For example, I find that Composer is something that is very useful. It allows me to easily manage third-party libraries, update them as needed, and incorporate them into my projects.
Similarly, I find tools that examine my commits before sending them to GitHub useful because they allow me to catch code-quality issues that would otherwise take more time during the code review process.
The point I’m working towards is this:
At what point do the tools we’re using for development hinder our ability to build something and deliver something effectively?
There’s something about our field that compels us to feel the need to stay on the bleeding edge of technology. But I think there’s an important distinction to make: It’s one thing to be aware of a tool, but it’s one thing to use it.
The great thing about knowing something is available is having the ability for us to research it and determine if it’s of any use to us.
This isn’t a ground-breaking or new idea, but it’s one thing I think some of us bypass. Rather than researching and evaluating, we often skip it and see how quickly we can get to using it.
Putting It To Use
The advantage of putting something new to use is that we gain the benefits – or expected benefits – said utility is supposed to provide.
The danger in this is that the tool may not be around in six months, a year, or even two years and the technologies that it’s aiming to improve on may change while it doesn’t keep pace.
This is why it’s important to keep yourself aware of said utility while simultaneously determining whether or not it’s useful.
About This Simplicity Thing
Coming back to my original point, though, is this: If the amount of time it takes you to configure, learn, develop, implement, and use a new tool within your workflow, I think it’s worth considering whether or not it’s truly worth its time in your stack of tools.
Customers are not going to care whether or not you’re using whatever tool you may be using. They are trusting you to be a good steward of the solution that they are paying you to implement and part of that responsibility of being wise and diligent with your time.
If the utility you’re using is hindering said responsibility in any way, it may not be worth using for a given project.
And that’s ultimately what it comes down to for me: If what I’m using is helping me to build the best possible solution while not doing so at the expense of the customer, then it’s likely worth using. To that end, the simplest set of tools is often all that’s needed and nothing more.
Otherwise, it might be worth examining for use in a future project but not on the time of your customer.