While some like to say less is more, we know it isn’t always true. We would not tell a new employees we were going to pay them less and expect them to think they were getting more. So, when is less more?
As technology has evolved, we have learned about user interfaces. This is one example of where less is more. It is very similar to a popular concept in advertising. If we fill an ad with all the details that a consumer might want, the odds of them reading it drops dramatically. Both of these are examples of where less is more.
Now we will look at a number of ways this plays out in creating and maintaining software.
Verbose vs. Elegant Code
When it comes to creating technology, the scripts that run behind the scenes, this truth is also true there. We use big words like ‘verbose’ to describe more in code. We use words like ‘elegant’ to describe software that is easier to read. Great software reads in a fluent way that requires less documentation to tell us what the code is doing.
Here are a few possible goals for creating software.
- Reliable/Stable Software
- Usable Software
- Faster Delivery
- Supportable for Updates
- Better team engagement during the creation
- Customer first focus
- Profitable
Many old solutions were winning, and the goal was to learn to win more effectively. Verbose code is more of a challenge to reaching these goals. While we want less code, we want it to be elegant and not just less.
Teams tend to create what we call ‘best practices’ standards. Sometimes these best practices are a top-down independent view of how things should be done. Other times, the team members from the bottom up connect with the process of creating or updating the team standards. This pivot point can either create or reflect the culture where code is created.
The Code Garden
Good code within a team is like a good garden. If we see our garden as a single crop, we will treat everything like the same crop. That is functional for a farm but isn’t the same in a garden. Gardens may have tomatoes, cucumbers, beans, carrots, lettuce, peppers, okra, radishes, basil, and perhaps some flowers.
Developers are more organic than mechanical. Not all vegetables are grown exactly alike, and not all fruits are grown exactly alike. Thus even within technical areas, we will find developers are as unique as the different things we plant in our garden. Those plants are usually not the product. They are the producers.
My point in the discussion on the code garden is seeing the value of elegant code is seeing the developer as part of the process of creating and maintaining code. Developers have many things in common, but each developer and each team is unique. When things are verbose, it is harder to be agile.
The Goal of Codeless
We have all seen very creative processes that started out simple and grew in complexity. At first, you may assume the complex process I am speaking of is code, the programs we write. While it could be, my actual focus is on the elaborate and extreme spreadsheets we have seen created over the years. This is not the goal of codeless, but it has inspired it.
It is also true that people creating spreadsheets rightly know not everything needs to be written as a custom software solution. Just because we moved beyond a calculator doesn’t mean we are in the code zone. Spreadsheets are an awesome example of going codeless. Originally there was a clear gap between when we needed to move to code and leave the spreadsheet behind.
Along come companies producing products like AirTable. This innovation took the concept of a spreadsheet to the level that used to be wrong. People love lists and love to be able to associate lists with each other. This used to be something that required expert database managers. It still has some technical aspects, but it is far more approachable than it was in the past.
What has happened is through user interfaces, learning usability, and advances in tools, the line has moved. It has drastically moved. This also exists in products that allow people to create apps without writing code. We are going to limit to AirTable because it makes the point so well. Granted, it may or may or may not fit into your budget, but it does start at nice free levels, so check it out if you want to explore the concepts.
The Goal of Less Code
The flow of history helps us understand many less code solutions of the past. Today, some developers look at browser code and ask why we created solutions like jQuery. Today the way browsers work is very close, so the need for less code solutions like jQuery confuses us in the present.
Browsers in the past were on their own path, and site visitors wanted the same experience. It was not prudent to create the solutions manually. This is why businesses in times past would standardize and mandate the browser that was used by internal apps. Consumer facing apps didn’t have that control, and tools like jQuery came to the rescue. The same code, less code, made production faster and the results more reliable.
Today the revolution continues. There was a day when we all wrote our database code individually based on the back-end database. Each database vendor, even today, has nuances that make universal code difficult when custom bach end database choices are not the same everywhere the code is run. Thus we have solutions like Quick using qb for CFML, Artisan for PHP, and Entity Framework for dotNET. All are producing less code and cleaner solutions.
Currently, we are exploring innovations like Supabase, and Firebase. In Supabase, you create your data tables, and the API for interacting with your data is automatically generated without writing a line of code. When we do testing, one of the rules is not to test external items that are already tested inside our testing. It is redundant and counterproductive. If we wrote our own API, it would require a whole lot of testing. So time saved not creating the API, and time saved not maintaining testing for these features. Win-Win.
Is Less More?
Sometimes yes, sometimes no. That is a question we should always ask. We should ask before committing, and we should ask before rejecting the solutions.
Can Codeless be more?
Specifically, one of the things I like about AirTable is the developer aspect. While you may think it pivots away from development, you would be wrong. It does much more without development before you need to move toward development. Then, again, rather than pivoting away from AirTable, as we would pivot away from a spreadsheet, it has a developer interface to allow integration with external solutions. Kudos on collaboration and agility!
Can Less Code be More?
For this example, yes, this is why we choose the examples of Appwrite, Firebase, and Supabase and the API. But wait, there is more! (Hats off to Steve Jobs for making that phrase iconically awesome.)
If the API doesn’t do everything you want, they have Edge Functions to do what the API does not. They also integrate authentication and storage. The benefits don’t stop at code. If you are a startup or small business, this delays the need to spend on staffing an IT department with deployment specialists.
This Won’t Hurt A Bit
If you are in systems administration, I get it. These solutions seem to impact opportunities for both of us. Yet, it is the future, and we will have other opportunities if we don’t let our nostalgia turn into a demand that others get stuck in the past. As tech people and as tech companies, we need to move forward as technology disrupts our familiar paradigms.
So again, let me ask, how will technology influence your future today?
Recent Comments