The Thin Line Between Flexibility, Readability, and Scalability in Software Development

Do you know that feeling when your managers have a problem to solve and they ask you to come up with a solution?

The programmer, developer, coder, or nerd inside you thinks, “Yes, I’m going to rock this! I’m going to blow everyone’s minds with my super-smart solution.”

If you know this feeling, keep reading because this can cause several dangerous situations for the business.

In this story, I want to dive into the danger of over-engineering. I want to show you that there is a very thin line between building a solution that is good enough and over-engineered solutions.

I’m not going to tell you what the best solution is. I want to make you think about this carefully because these situations and decisions can have a big impact on the timeline of the development phase.

Design a Rock-Solid Architecture

Most developers are happy to dive into a problem and make the best solution there is. We are very devoted to putting everything in our power and ability into this solution.

You probably recognize the great architecture you and your team came up with and you were all stoked about it.

Maybe you were on fire and confident that you were going to rock this. There is no doubt that something comes between that.

And then your manager comes in, and you have a time frame of six months.

Ouch, there goes the plan!

But you and your team find a way to make the architecture a little bit less awesome — but still awesome enough.

You and your team start building day in and day out.

Reusable or Not

Weeks go by and you’re building lots of components.

It gets the data from the APIs and shows all the data.

You’re building a service to transform all data models into forms. This is super awesome!

So you build a service that can be used everywhere.

But what happens when a data model changes? Is it still going to work or are you and your team going to have a big issue because everything is connected to this service?

That deadline is coming closer and closer!

So, is it a better idea to make all the components use this service or build it specifically?

Lean or Not

Maybe it’d be better if you and your team kept it things simpler. Just building what was asked or defined in a very lean way — nothing more.

Sometimes, it can be good to start specifically! Just building what is the absolute minimum of a solution. Let testers, managers, or users test it first.

After that, you have data to improve it.

Maybe the flow is good, but the performance is lacking. Then you can improve just that!

You remove code that is not needed and maybe make some pieces reusable.

Is that the best solution or is it better to work out the complete architecture?

Flexibility, Readability, and Scalability

Everyone knows that these traits are very important. You want to keep your code readable so others can contribute to it.

On the other side, it needs to be flexible so you can use it for a long time.

Next to that, you want to make the application scalable in multiple ways. But how do you do that when you want to keep the readability?

If you go all-in on flexibility and scalability, it can cause a great deal of complexity that reduces your readability. Do you want that?

If you go all-in on readability, it can cause performance issues that reduce the flexibility and scalability of the application. Do you want that?

You see a very thin line between them. The choices make or break the success of the application.

Specific or Generic

Like I said earlier about the lean method, you can start very specifically and build only the bare minimum solution.

But this can cost more time. That way, you may need more iterations to improve the application.

You can also choose to start with a great plan for a rock-solid architecture that is very generic and flexible.

This can help build an application that improves flexibility and scalability. But at what cost?

Building generic classes, functions, or components will reduce readability — especially for people who are just diving into it.

It can even become a problem if that code needs to be changed because of new insights into the user experience.

At that moment, was it better to write it more specifically or generically?

I’ve gathered a couple of aspiring developers around the world on a Discord server, feel free if you like to join in.

Conclusion

A lot of open questions!

There is a very thin line between readability, flexibility, and scalability when building an application.

If you go for lean and you start very specifically, when do you start improving and make the code more D.R.Y.? When is it acceptable to make the code less readable?

Maybe it’s better to have some parts be specific and some generic.

But what is most important — no matter what you and your team decide on — is that you talk with each other about this. Leave no room for interpretation. This will become deadly for the team bond.

No matter what you and your team decide to do, write it down. Tell your manager what you have decided and work with that.

If things don’t work, change them until they do.

If you have some thoughts on this topic, share them in the comments so we can learn from each other.

Happy coding! 🚀