How you approach developing software changes with the maturity of the business.

I recently had a good discussion with my team about the different stages of business software. In particular, we find ourselves with a sprawling "legacy system" for all our internal operations. But most of our new dev efforts are about creating products tailored to specific workflows. The maintenance experience is night and day between them. In the legacy system, each major feature costs drastically more than the previous one. Whereas in the new system, learning the business workflows and thinking through designs are important first steps before we write code. And with a few years of history now, these products prove to be quite maintainable by comparison.

Early Stage Businesses

I used to think that if we had access to an experienced person at the time the legacy system was started, it would be more maintainable than it is now. Certainly it would have been to a degree. But I've changed my mind that it would have fixed all our current maintainability ills. And in fact, I do not think our current development process would have worked out very well back then. The reason is pretty simple... the business processes were still fluid or undefined. So we could not have written software to capture them. At the end of the day, we had to write data-centric software just to capture the data they believed they needed.

This data-centric software is usually referred to as CRUD. It is great at getting you started. But eventually as the business grows, processes start to become more formalized. Then the data-centric approach starts to chafe. The business asks for rules and logic to be applied to the data, but the system is just not geared to make that easy. Since the system is just about data, a lot of the user's intent is lost -- you don't really know why a given change was made. Data updates are destructive, so past history is lost. The rules and logic you write end up being guesses about what the user was trying to do based on the contents of the data, so they are difficult to get right. This kind of code can also be brittle when the user saves unexpected data. Sometimes the user can literally break the system by saving the wrong data.

But the system continues to function and provide value to the business, so it is difficult to justify migrating away from it. Now there are many business apps -- internal and external -- running against the same database, aka an Integration Database. Eventually, the powers that be start to realize that it takes a long time to train new employees. Thanks in large part to having to know all the minutiae and work-arounds of the data-centric system. In essence the user has to load the "program" in their mind and execute it consistently, which takes time and practice. Additionally, developing new features becomes very expensive. Not necessarily because of the dev time it takes, but because it is hardly possible to consider every possible permutation of data in the database (that was, is, and ever will be). So changes have an ever-increasing risk of breaking something... if not today, then perhaps quite unexpectedly tomorrow. And despite spending an unreasonable amount of time testing, there will still be production issues. They are not easily avoidable... not with unit tests or coding practices or anything else (although these do help). The problem is that the system was (rightfully at the time) designed to store data, and the business workflows built on top of them are extremely sensitive to variations in data.

Solid Processes

At this point, the business is in a place where they can actually benefit from software that represents their workflows. This is a place where you could bring in a task-oriented UI. Where you can capture user intent, and record business-relevant events. And these change at a reasonable-enough clip that they are not cost-prohibitive to code. And this all transfers into external products that we are creating. We can tap experts in the company to help us understand the business factors at play and design accordingly. This is the journey we find ourselves on now.

Perhaps it would have been possible in the early days to sit down with the leadership and formalize business processes ahead of time instead of going data centric. But certainly the processes would have been guesses about the future and mostly wrong. It would need a lot of ongoing development work to change quickly with the business -- which would have been expensive. Data-centric allows the processes to be malleable in those early stages because they are in the user's head rather than the software. And the processes are few enough to be quickly learnable. The main development work is just adding more places to store more data, so it's less frequent, costing less. It isn't until later that the cost of this kind of system begins to outweigh its utility.