Lessons learned from software development experience

Here is a list of software development rules that I have developed for myself over the years of practice.

1. Start with small things, then expand them

As when creating something new, and when adding functionality to ready-made systems, I always start with a very simple version that does almost nothing of the necessary functions. Then I expand this solution step by step until it becomes what was originally stated. I have never managed to paint in plan all the details already at the start. Instead, I better and better understand what you need to get during the development process and use this knowledge in the project.

I like these words of John Gall: “Any fairly complex system that works, somehow evolved from a simple system that worked in one way or another”.

2. Change something one at a time

If during development a program starts to fail on some test or some function stops working, it is much easier to find the reason if you changed the code in only one place. In other words, it is better to use small iterations than trying to do everything all at once. Do one thing, make sure it works, repeat.

This also applies at the level of commits to the version control system. If you need to refactor, then before adding any new feature, first commit the changes for refactoring, and only then (in a separate commit) add this feature.

3. Add logging and error handling in the early stages

When I set about developing a new system, one of the first things I do is add logging and error handling. Both of these things are beneficial from the very beginning of the project. In any program that has more than a couple dozen lines of code, you need to know what happens during execution. And especially this data is important when something doesn’t work as planned.

Roughly the same thing with error handling – since exceptions can still not be avoided, and they will be thrown throughout the life of the project, why not start processing them systematically at the very beginning?

4. Each new line of code must be executed at least once

Before you finish work on any functionality, you need to test it. After all, otherwise how do you understand that she is doing exactly what she should? Often the best option for this is automatic tests, although there are other options. In general, it doesn’t matter how, but the main thing is that every line of code you write should get control.

It can sometimes be difficult to reproduce the necessary conditions to go into all branches of the code. Fortunately, you have the opportunity to cheat a little, it is not necessary to try to reproduce fully combat conditions. For example, catching database errors can be checked by specifically making a mistake in writing the column name. Or you can temporarily invert the condition inside the if, then the case “an error occurred” will be interchanged with “everything went correctly.” This is useful for errors that, in principle, are very rare and difficult to imitate.

Sometimes I come across bugs that show that a certain line of code should never work at all. It may look quite normal in appearance during the code-review, but still not work as it should. You will avoid such situations if you make it a rule to always execute at least once every new line.

5. Test in parts before checking the entire project for operability

The more thoroughly you test individual components, the more time you save. Often you may encounter the problem of adjusting the interaction between the individual components. And if you are sure that each of them works correctly, you can devote sufficient time to solving this problem.

6. Absolutely everything takes longer than you think

Especially in programming. It is really difficult to assess how much time it will take to implement a given task, even if everything goes smoothly. But when it comes to software development, it is necessary to take into account the fact that unexpected problems may arise: a bug can sneak into the simplest merge, updating the framework will necessitate changing some functions, or calling the API will give an unpredictable or incorrect result.

It seems that the old man Hofstadter was right when he formulated his law: “Any business requires more time than it seemed at the beginning, even if you took into account the law of Hofstadter”.

7. First understand what this code does

For the most part, programming involves modifying existing code. Even if you included something completely new in the project, this new should become part of the written code. Moreover, it is necessary to understand the solution found before adding it. Otherwise, you may disrupt the performance of something that has already been implemented. Therefore, the ability to read code is as important as the ability to write it. And this is another reason why a seemingly simple task of embedding code may take longer than it seems: you need to understand the context in which changes occur.

8. Read and run the code

Fortunately, there are two methods of understanding the code that complement each other perfectly. You can read the code and you can watch what happens when it runs. Launching for execution can help you a lot in understanding what this code was written for. But make sure you use both approaches. Learn more at Ecodelogic, this custom software development company in Orlando has an excellent rating and experts are there to always help you out.