What software developers can do to prevent things from being forgotten or overlooked - Wishevoke

What software developers can do to prevent things from being forgotten or overlooked

According to Ilian Iliev, software developers tend to forget things that they don’t have to think about every day, which can cause delays or affect the functionality of the product during a software project. To avoid missing anything, he suggested starting to automate deployment early, setting up error logging, and using lists and reminders for previously forgotten things.

Ilian Iliev talked about what software developers can do to prevent things from being overlooked Dev Challenge accepted 2023.

People tend to do that Don’t overlook things when developing a new software product or service because they don’t have to think about it every day, Iliev said. This could cause delays in your software project, affect the functionality of your product, or both, he said. Anything you forget during the planning phase means either pushing back the deadline or cutting corners and publishing less than promised:

Imagine that two days before release you suddenly realize that you have completely ignored the fact that existing data is incompatible with the new version of your application and that you have neglected to develop a migration plan. This could mean a few days delay or weeks of reorganization depending on your specific circumstances.

Iliev recalled how one of their servers crashed in the middle of the night due to a leap second processing error in the operating system:

The entire system was operational, except for the part that processed customers’ orders. The problem was that we found out about this a few days later when a customer called and asked why the system still hadn’t processed their order.

“It was a blow to the company’s reputation and also to our self-esteem as developers, because we never thought of monitoring this thing 24/7,” Iliev said.

One of the things to focus on earlier from a deployment and operations perspective is automating deployments, Iliev said. You don’t need a complex CI/CD pipeline; “Of course they’re great, but to get started, maybe a simple script that just runs all the steps might be enough,” he said. Just don’t rely on people remembering to run five different commands in a specific order, even if they are documented. Deployment should be a one-click or command thing, Iliev said.

Availability monitoring and alerting are a must for operations, Iliev argued. This also applies to proper error logging; If something goes wrong with your system, you should be able to pinpoint the cause, he added:

Without proper logging, you end up guessing what’s causing a problem or, even worse, you don’t know about it until customers start complaining.

Iliev mentioned that saying something is a bad decision is often interpreted as hostile and also doesn’t add any value to the discussion. He suggested expressing concern that something might not work by giving concrete reasons, which opens up the possibility of identifying potential problems early.

Software developers shouldn’t be afraid to ask questions outside their department, Iliev said. “In the end, all of our work is combined together, so it is important to have a general understanding of all other aspects to better integrate all parts into the final product,” he added.

Iliev advised teams when starting a new project to think about everything that went wrong last time and make sure it doesn’t happen again:

Consider how your product will evolve and how you will maintain the system. Maintain good communication between teams and ensure everyone involved is aware of all complexities and potential pitfalls.

There will always be things to forget or overlook, but the fewer there are, the better the outcome, he concluded.

InfoQ interviewed Ilian Iliev about how developers can avoid missing something.

InfoQ: What advice do you have for teams starting to develop a new system or product?

Ilian Iliev: Using a checklist of topics to pay attention to in the process helps a lot. Divide it into sections for each phase and use it both as a tool for checking completion of specific steps and as a source of questions to help you better understand the project requirements. The advantage of these checklists is that they can be reviewed quickly and help you avoid missing steps that could lead to future problems.

InfoQ: Can you give an example of what such a checklist might look like?

Iliev: I created a Github project with Project checklists It contains drafts of the checklists I use in the areas of architecture, implementation, deployment and operations, and development and maintenance.

Here are two excerpts from the checklist to inspire you as you create your own checklist:


  • documentation

    • Documentation of data models – what different attributes represent
    • APIs documentation – what the endpoints do, what the expected inputs and outputs are
    • Business logic – why certain decisions were made

  • Code quality – style guide, linters, review processes
  • Versioning
  • Stability – Unit testing, end-to-end and integration testing, load testing

Deployment and operation:

  • Deploy with a single command
  • Availability Monitoring – Are you sure your system is running?
  • Metric Reports – How to measure system performance
  • Error logging – Operational logs should be easily accessible and understandable
  • Silent services – the system should not generate unnecessary noise, e.g. E.g. logs, emails, notifications, as these can obscure actual problems

Leave a Comment

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

Scroll to Top