By Peter Grainger December 12, 2018

Simple Solutions for Simple Problems in Code Development

JavaScript fatigue is a real thing. There are so many new frameworks that it is difficult to keep up. This makes it difficult when the time comes to start a new project and you are the one to figure out the best solution from scratch.

There are many factors affecting the choice of tools for a particular job; the weight of each choice depends on the project but the most important choices normally favor maintenance over performance. There are instances where performance is king, like searching algorithms, but we mere mortals don’t normally have to think about that.

Choosing Your Tools

Use the Tools Your Team Knows Well

Tools in this context are any software (as a service or downloaded) that enables the creation of the solution, like a hosting service or a text editor.

This may be the most important factor. You might have hundreds on your team, or you may be the only one, but as long as the majority of the team is familiar with the tools and how to use them, that is enough. People are much more important than the best technical solution. The best technical solution will end up as a mess of code as the team gets familiar with the technology.

Make It Sustainable

Most software lasts much longer than first anticipated, so keep in mind who will fix any bugs that arise or who will add new features. There are hundreds of Angular 1.x apps that have been abandoned or that the team is too scared to touch. Who wants to work on a technology no one uses anymore?

Make sure you don’t commit too hard to any specific technology, and have a backup plan to revert to a different technology if needed. Software languages and frameworks that have been around for many years may be old, but that does not mean they are obsolete. Be clear on the resources available to you and whether they will always be available. If there is money now, is it guaranteed for the life of the project?

Buy Over Build

I am a huge fan of buying over building. If there is software as a service (SaaS) that provides at least 80 percent of the functionality you are looking for, it is better to buy and focus on higher-level problems. You can always return to the problem and make a bespoke solution if the cost starts becoming an issue.

Understand Your Audience

Understand what your users are trying to achieve, and create just that solution. Don’t overcomplicate. Try not to copy a solution from a different site; the goal of that page may be different.

Write the Minimum Amount of Code Possible

As developers, we often try and think of all of the edgecases and design something that works for all scenarios. That is good for unit tests but not good for designing the best solution to a problem. In most cases 80 percent of the effects come from 20 percent of the effort. Designing for an edgecase is not included in that productive 20 percent. Write just enough code to satisfy your goal, and then stop.

Don’t Prematurely Optimize Your Solution

Premature optimization in code is widely seen as an anti-pattern. It can also happen when designing a solution. It may seem like a pragmatic choice to choose a framework so you are not reinventing the wheel, but with all that power comes great complexity.

You need to figure out if it’s worth it in the long run or if simple JavaScript, HTML, and CSS is good enough. You can always refactor, and the less code you write, the less painful it is to scrap it and start again.

An Example From Real Life

Waste plastic is a massive problem. All the plastic that was ever made is still somewhere in the world. Your first toothbrush? Still out there somewhere. I hate waste and was happy when a friend asked me for help create a simple map of everyone in the UK who is making or collecting ecobricks.

For the uninitiated, ecobricks are plastic bottles stuffed tightly with little bits of unrecyclable plastic to make an eco-friendly alternative to building materials. There is loads of information on the site https://ecobricks.org.

Ecobricks are very popular in some countries, such as Indonesia and South Africa, but not so much in UK. In those countries there are loads of drop-off locations for the bricks, but in the UK, it is more of an ad hoc arrangement between the makers and the builders.

This is where I thought I could contribute; a common question on the Facebook Group was where to drop off completed ecobricks. That gave me a place to start my solution.

Using the Tools My Team Knows

The tools I personally use include modern front end frameworks and the latest JavaScript or typescript usually involving build steps to automate away most of the boilerplate. It was tempting to pick up my go-to stack, Vue coupled with Node and MongoDB.

In this case, however, I need to think about the whole team and their skills. I’m making this site with another programmer who is experienced but in different technologies. We both are heavily into the tools Google puts out there, like Sheets, Forms, and Maps, so they look like a great fit for this solution.

Making It at Zero Cost

In the UK, this collective of people collecting ecobricks hasn’t formed into a charity, so there is no sustainable money source to fund the running of any servers or buying any SaaS products. Also, any time anyone takes to contribute toward the site and its upkeep is also voluntary and unpaid.

This makes it really important to keep running cost as close to zero as possible while keeping the project as simple as possible, so the ideal solution would be as little bespoke code as possible.

Understanding What Ecobrickers Want

Listening to the other members of the “Ecobricks UK” Facebook group, most new members wanted to know where to drop their ecobricks off near their location, that’s it, no complicated logging in or information about how to make one. That was all on the Facebook page.

Writing Minimal Code

We need a webpage with a map that stores the smallest amount of data as possible so a login isn’t required. It also has to have as close to zero running costs as possible and have as little bespoke code for easy maintenance.

Don’t Prematurely Optimize Your Solution

As an engineer it is very tempting to code all of the components needed to make this work. A site with fancy graphics, a great form that posts to an API that saves the data in a database to be retrieved by a map. However, your solution, no matter how well engineered, may never get used and may never solve the original problem because you may never have understood what the audience really wanted in the first place.

Sometimes I make programs for myself, get sidetracked, and the final solution does not solve my original problem. Best to make it as simple as possible and get it in users’ hands as early as possible. This means keep the solution to a map and a form, using Google SaaS products where we can.

The Solution

Easy-To-Find Ecobrick Collectors

The goal is to minimize the time it takes from typing www.ecobricks.org into the browser to finding a collection point.

To achieve this we need a fast loading page with as small amount of user interaction to get to the information they are looking for as possible. A map is the easiest way to visually work out the nearest location without complicated searching. It also makes the page more friendly than just text.

The first iteration should be as simple as possible—a single webpage with a map and buttons to sign up as a collector or a maker.

problems in code development

Cheap or Free Upfront and Ongoing Costs

SaaS solutions are popping up everywhere. The simplest ones I have used are Glitch and Now, which are both free for small amounts of use in open source. Glitch allows us to collaborate on code and Now lets us deploy when we are happy with what we have. We even managed to talk to the maintainers at ecobricks.org to get uk.ecobricks.org to point to our site, which, when coupled with hosting a static site on Now, comes to zero costs!

Least Amount of Bespoke Code Used

The best way to achieve a minimum of bespoke code is to use as many free third-party solutions as possible. The form uses Google Forms, which are stored in a Google Sheet that we are using as our data store. The map uses sheetsee, a JavaScript library that is built to use Google Sheets as the data source. A little configuration and we have a working map.

problems in code development

We Used the Tools We Knew Well

Programming language, build system, and deploy procedure should be simple and well documented for future maintainers. Because the form and data store are third-party tools, and the only code used is HTML, CSS, and JavaScript to display the map, the full code can be seen on Glitch https://glitch.com/edit/#!/momentous-sawfish along with a full explanation of how to set up your own site in the same way.

Make Your Simple Solution

Ask yourself what is the simplest solution that will get you the outcome you’re looking for, and then make and test out your theories. The more code you write, the more invested you are in a solution. The first iteration of the site had less than 200 lines of JavaScript, CSS and HTML. This makes it easier to read, easier to modify, and, most of all, fun to contribute to.

Be happy if your solution fails the first time; you didn’t waste too much time, and it means your next try will be much better!

About the author

    Peter Grainger

    Helping developers write amazing low maintenance solutions with maintainable code to get those features out quickly. Preferred tech stack is full javascript from API to end to end tests (Node.js, Docker, MongoDB, puppeteer) to get that code out there quick and create some value! See grainger.xyz for more posts like this.