When a Small Change Alters the Entire Software Structure

One of the experiences I gained in software design and development involved an online payroll system that I had designed for companies and organizations.

In this system, customers could upload payroll information for several thousand employees through an Excel file with a specific format and structure. The data could be processed in a short time and payroll slips generated automatically. Employees could then log into their user accounts and view their payroll slips.

Initially, the Excel file structure was clearly defined and fixed, and the system was designed around that structure.

A few months later, the accounting department of one organization contacted me and explained that the organization's IT department had changed the Excel file structure. The new file no longer followed the previous column-based structure and was instead provided in a matrix format.

This change created a major problem for the accounting department. They needed to enter information for several hundred employees, and manually converting the new file back to the previous format was extremely difficult and time-consuming. At the same time, the change had been mandated by the organization, so the accounting department had no practical way to object or request a return to the previous format.

After reviewing the situation, I decided that instead of asking them to convert the information back to the old format, I would adapt the software itself to work with the new conditions.

On the surface, only the structure of the Excel file had changed. In practice, however, this change affected different parts of the software, requiring modifications to parts of the application logic, data structures, and related data-processing components.

At the same time, there was another important issue.

The information from previous months, which had been entered using the old structure, had to remain unaffected by the change. Employees still needed to be able to view their previous payroll slips, and all existing information had to remain intact and accessible.

After the changes were implemented, the system was able to recognize and process the new file structure as well, allowing the accounting department to continue working without manually converting the data.

But that was not the end of the story.

Over time, similar changes happened several more times, and each one gave me another valuable experience. Gradually, I realized that I could not design software based only on today's conditions. In the real world, organizations and their processes change, and software should be capable of adapting to those changes as much as reasonably possible.

This experience led me to change my approach as I continued developing the product. I began designing the software in a more flexible way so that it could support a wider range of structures and conditions, while allowing future changes to be managed with minimal dependence on major modifications to the application.

One of my goals was to make sure that customers would not have to pay for software modifications every time a small change occurred.

Interestingly, some time later, the organization's accountant told me that the system's ability to convert the new matrix-style Excel structure into payroll slips had also attracted the attention and surprise of senior technical managers within the organization.

The Lesson This Experience Taught Me

This experience taught me that software flexibility is not something we should think about only when a problem occurs; it should be considered from the design stage.

A requirement may appear completely clear and stable when a project begins, but circumstances can change several months or years later.

Not every small change is necessarily a small change from a technical perspective. Sometimes, changing an input format can affect the database, processing logic, and different parts of the software.

For this reason, one of the things I began paying more attention to in later software designs was making the system reasonably adaptable to future changes, so that every small change would not require rewriting fundamental parts of the system.

In the end, a mandatory change that had initially created a problem for the customer became a valuable experience for me—one that later influenced the design of subsequent versions of the same product as well as other software products.