Building quality software is hard

Building quality software is very hard, even for the most experienced, and choosing the wrong tools for the task can completely break your project.

Version 1.0 is not the end of the road

Writing the first version of an application that solve a specific problem is easy, any developer can do it. On the other hand, creating applications that resist years of changes, upgrades, improvements and updates without compromising the quality of the product, that’s another story.

Every time a team faces the construction of a new application, someone has to make decisions about what technologies and frameworks they will use. Not an easy task.

Some developers like to take risks and learn new stuff. Others tend to keep using whatever they already know and play it safe. In addition, managers and decision makers tend to ask questions like

Will this framework help us deliver the project on time?
or
Is this new framework easy to use?

But these concerns are fundamentally flawed. Here´s why:

When a project reaches successfully the end of it´s first stage, chances are it’s only the beginning of it’s life. In subsequent stages the product will be an entirely different one. This usually happens much faster that expected.

Quality software that solves real world problems almost never can be considered finished because users will always want more features.

They will soon want it better, faster, prettier. Then, business rules change. People come and people go, teams change fast. New ideas and needs arise. In addition, problems impossible to predict from the beginning start to show up, so how do you plan for that?

First point of failure

From zero to v1.0

The vast majority of software projects can go from zero to v1.0, no matter what tools and technologies you choose for the task. The real problem still does not exist during that phase.

The product is up and running on production. Users are happy with it, they may find a few bugs but nothing critical. Your team will solve them on future releases. They will publish new features too. Everyone is happy. Good job! What’s next? Time to think about the next phase.

Intermezzo

Here is an incomplete list of things that might happen between completion of v1.0 and the start of v2.0:

  • Developers leave the team and new ones arrive.
  • Business rules that were valid before, are now invalid.
  • Business processes grow more sophisticated, frequently, thanks to their successful implementation on the software project, especially when the users didn’t have any process definition at all before.
  • Users that wrote the original requirements leave their organizations too or acquire new responsibilities. New business users come with different opinions, potentially conflicting with the current implementation.

Point of no return

Construction of v2.0 begins as scheduled but now everything seems so different than the start of v1.0.

I said you can complete v1.0 of almost every software project no matter what technologies were selected. For subsequent phases that does not apply anymore. That’s because now you are building on top of a product that is actively used and must not be broken. This changes everything.

This is the point where it becomes clear if you chose the right technologies for the project.

Signs that the project was built with the wrong tools:

  • The source code is too complex, new developers do not understand it easily and spend more time trying to decipher it than focusing on building new requirements.
  • New requirements do not fit easily on the existing application. Every change to the structure of the application solves one problem but breaks something that worked before.
  • Less experienced developers made a mess with their code and nothing stopped them. Integrations become more difficult every time.
  • You have to apply dirty hacks to the code to meet new expectations.

If your project looks like this you may be at high risk of failure. This is the point of no return, you either rebuild your project with better tools or try to maintain it, accumulating risks and waiting for it to blow up

Planning for the future

Modern development methodologies (agile, DevOps) certainly help making projects flow nicely. But let´s face it, methodology alone is not enough. It seems we are not planning for success from the beginning. That is to say, we should not aim only for version 1.0 of our product. Instead, we need to consider future versions from the very beginning to achieve quality software.

It seems we are not planning for success from the beginning. That is to say, we should not aim only for version 1.0 of our product. Instead, we need to consider future versions from the very beginning to achieve quality software.

When you aim for the long term, the right questions to ask should not focus on the learning curve of the tools or if they can get you started quickly. We need to take in consideration what will happen months, or better, years after the first version is up and running.

Remember we are talking about successful applications. We should ask ourselves if any given technology is strong against any kind of changes the project will demand in the future. For example, how will the application respond to big changes in the data structure, updates due to new government regulations, new tasks on a business process, etc.

An application that successfully solves a set of user’s needs is destined to stay up and running for years. Choose the right tools from the beginning to keep your users happy. And the development team too.

On future posts I will provide a series of tutorials and examples on some tools that helped us building quality software applications. Java with Spring for example. Front end frameworks such as EmberJS to build strong user interfaces. MyBatis and PostgreSQL to handle the persistence layer. Camunda and Activiti for Business Process Management, among others.

Leave a Reply

Your email address will not be published. Required fields are marked *