Prerequisites: Plan Before You Code

Currently, Frederic and I are developing PayrollRabbit, a payroll management software. For this project, we decided to do the prerequisite work before construction.

In previous projects, we began coding immediately once we had business ideas. We worked on requirements, architecture, and design while coding, without clearly distinguishing them from construction.

However, there were always things that I wished we had specified earlier. I often realised that changing things later takes so much time. A slight change in the code after almost finishing it takes a lot of time because I also need to ensure that the tiny change does not affect other parts of the code, and everything else works fine as before. Of course, it is impossible to define everything beforehand, but we can at least have a blueprint in hand.

It's also a coincidence that I'm currently reading "Code Complete, 2nd Edition" by Steve McConnell, which has convinced me that upstream prerequisites are essential. There is already a lot of research on how to make great software, so why not follow it?

Upstream prerequisites consist of three activities: 1. problem definition, 2. requirements, and 3. software architecture.

1. Problem definition

Albert Einstein once said, "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions." Defining the problem you want to solve is crucial, as solving the wrong problem will waste your entire time building the software. To avoid this, it is better to define the problem well before starting coding. Also, when you write a problem definition, you need to be sure that it sounds like a problem, not a solution. You should also describe it from the user's point of view.

2. Requirements

It consists of functional requirements and nonfunctional (quality) requirements. Functional requirements are the types of functionality that the user needs to solve the problem. Nonfunctional requirements describe operating capabilities, including response time, security level, and so on. You should write requirements from the user's perspective, not the developer's. I found it very useful to do this at this point because I often struggle to adopt the user's point of view while coding (I tend to approach problems from a developer's perspective).

3. Software architecture

Software architecture is a vast topic that I cannot fully describe here, and I intend to learn more about it in the future. But it is similar to the architecture of buildings. Without well-thought-out architecture, construction fails. It defines major building blocks, specifies critical classes, describes files and table designs, and so on. You should organise the overall program and justify it. (Why this way, and not that way?) Good software architecture guides programmers throughout the construction process. We found the Software Architecture Canvas of arc42 very useful for this purpose. It is a template for documenting software architecture, is free to use and available in multiple languages.

Conclusion

Of course, even if you prepare, things will change, or certain aspects may be unknown at first and revealed during the construction process. It is better to be well-prepared, but also be flexible, so that you can adapt to changes. The amount you should spend on each activity above also varies depending on the type of project, its size, and other factors.

We spent a week completing all the prerequisite work this time, and the construction process is proceeding much faster than in previous projects. Even within a team of two people, it was beneficial to communicate about the project's foundation and agree on it first. I recommend spending a suitable amount of time (neither too long nor too short) on the prerequisites before construction for any software development project.