Today’s coding landscape has created new demands on engineering teams. Code must be more concise and more readable. The old adage that brevity is the soul of wit has never rung more true in the software engineering world than it does right now.
Any software team might only own a project for a few months or a couple of years before they move on to something else. That means every line of code has the potential to essentially be “someone else’s code.” When that happens, projects can become the victims of dense, bloated, and sometimes unreadable code.
After all, that’s a big reason behind the push to adopt Agile.
Leaning into Agile
A rarely spoken underpinning of Agile is that it must rest on a foundation of readable and concise code. If a team wants to be truly Agile, they must have excellent coding practices. Shorter, more readable code fits better with the Agile mindset. Gone are the days where engineers are endlessly producing code to create “The One True Project”—one with distended code that, frankly, may not ever ship. Instead, dev teams can focus on what can be accomplished in a shorter, time-bound period.
This is all about factoring your code to do one thing really well. ”Shorter code” isn’t a goal, it’s an outcome of better architecture. If you factor your code down so that each function, class, or microservice does one thing really well, then you’re naturally going to wind up with shorter code. It’s when we default back to monolithic, multi-function code that we end up with longer and more complex code that’s harder to maintain over time.
Prioritizing Attitude Over Tools
This philosophy is for the most part language and tool agnostic. Attitude and patterns are far more important. C#, Java, Javascript, Python, PHP—the names are all the same here. What’s changing is a willingness to use all of those in the right place and time, versus shoehorning everyone into a single language.
It is true that legacy languages like C, C++, and maybe COBOL can force engineers into patterns. But even venerable languages like C#, Javascript, and Java have kept up with the times. Once again, the key is to ensure you are using your language to the best of its capabilities. PHP is a shining example of this trend. Engineers can continue to write long procedural code in the latest versions, but PHP also supports much more modern, concise, and readable patterns for people who’ve taken the time to learn those functions.
A potential danger of more concise code is when you over pivot. Some developers will read “concise” and get into competitions about who can write what in how few lines of code. Obfuscating your code in the name of “being concise” is just being evil. It doesn’t help long-term maintenance because the flow of logic in longer-form code can often be easier to follow. This is why we talk about shorter AND more readable code: if you do both, there aren’t a lot of cons.
Towards a More Concise Future
The need for an Agile approach to coding accompanies a general shift towards flexibility and adaptability in engineering teams. Being forced to work remotely for the better part of two years has caused many companies to let go of timeworn attitudes about what “can” and “can’t” be done remotely. Companies who’ve been dead-set against remote work were forced into it. With the ingenuity typical to our industry, they’ve made it work. That unlocks all kinds of opportunities—including the ability to hire people from nearly anywhere—which makes finding talent with a propensity for concise coding much easier.
In the coming years, more organizations will invest in frameworks and code libraries that make common tasks—such as accessing data stores or processing credit cards—faster for developers to implement. The industry will likely shift towards more automation in the “utility” work, like writing CRUD routines and such, or producing simple UIs. In the end, that automation will get rolled into frameworks so it’s even easier and more modular.
Setting aside the “utility code” that we all find boring to write, coding is very much an art. It’s no coincidence that so many developers have musical or artistic hobbies—we’re always going to seek to focus on the artistic components of the job. We’ll use libraries and automation for the boring bits, so we can focus on the real human-creativity bits.
In my view, there are few things more creative than generating elegant code that is both short AND readable. Let the artistry begin.
