Developing Software With the Next Developer in Mind

January 25, 2022
by
Jon Price

By focusing on how to make software more sustainable and user-centered from the start, the next developer benefits from being able to easily maintain and add to it in the future. Learn about several best practices C2 follows to ensure the software we develop is built with "the next developer in mind".

Development

Developing software is a human-centered effort. Whether it’s a website, mobile application, integration amongst existing systems, at the end of the day, it’s people that will use these tools and services. That means the products and solutions we build are only as effective as their users find them to be useful.

At C2, our philosophy revolves around designing and developing web solutions with the “next developer in mind” - whether that’s our own team of developers, a client’s, or another agency. By focusing on how to make a project more sustainable from the start, the next developer benefits from being able to easily maintain and add to it in the future.

Here are several best practices we follow to help future developers step into projects smoothly:

Understand the purpose of the software we’re building

Everything we build is in service to helping people. That’s why we don’t dive in without having a plan and purpose regardless of the project type.

Before we write a single line of code, we get an understanding of who it will serve, what it needs to do (functionality and features), and how it will drive the overall business. By defining the goals, objectives, and impact the project has on the business, we can deliver a stronger product.

For projects where we’re supporting or adding onto an existing solution, we generally start with a code audit. This helps both C2 and the client understand what’s going on in a codebase that has likely been touched by many hands over the years.

Make it usable, not just “work”

It’s not just about making the code “work”, it’s about making sure it’s usable. By “usability” of code we mean that it can be modified or fixed with ease (maintainability) and can easily extend by composing its parts.

We always keep the user in mind, whether that’s how a developer will contribute to code in the future, how a content editor will interact with the software’s user interface, or how a customer will engage with features or functionality on a website.

Focus on simplicity and consistency

We aim to make our code as legible and simple as possible. Despite writing code being an essential part of our job, so is reading it!

Writing excessive code is the figurative equivalent of welcoming bugs into your project. Rather than writing line after line of code until a function works, each function is focused on solving one problem or serving a purpose so it’s easier to read and test. We follow meaningful and consistent naming conventions for variables and functions, so any developer can quickly understand what’s going on.

Plus, by packaging code into smaller components, we can reuse code in other files and easily maintain and extend components as new requirements come up. We aim to control complexity, not create it.

Organize files and folders

Technically, you could write an entire solution’s code within a single file. But that would be a nightmare to read and maintain. As a project grows, code becomes harder to find, the project is harder to maintain, and there can be a lot of scrolling around the project to change code for a single feature.

We organize our solutions with a folder-by-feature structure. Each folder represents a single feature and includes any JavaScript, CSS, HTML, and other code required to create and maintain that single feature. This helps keep the application from becoming cluttered and make it easier to navigate.

Provide clear documentation

As mentioned before, each function should do one thing and one thing only. If our developers must explain what our code is doing, we’ve already failed in making that code usable. But, in the instances where code can’t be simplified anymore, we make sure to explain why we wrote it that way.

In addition to comments, documentation also helps us explain, train, and hand off the final solution to the client. We unpack the technology we used, the software’s architecture, and modules and components as necessary.

Consider future maintenance

Change is inevitable, so considering how the software will be maintained is a priority for our team. Maintenance is needed for any number of reasons: to keep it up and running, enhance features, rework the software for changes in the future, move to the cloud, or any other changes.

The effort of maintenance is proportional to the complexity of the software we build. Everything mentioned above are strategies to make maintenance easier.

Developing with the next developer mind is more than simply a mindset or best practice, it helps keep the client's heart of their business up and running. If your team could benefit from following these best practices in your current project or as you develop a new one, reach out to our team and we’d be happy to help.