First of I should apologize for the rambling nature of today’s posts. I just finished up a four hour requirements development meeting which has turned my brain into the consistency of tapioca pudding. The new project that I’m working on is a massive undertaking and we are working our way through a very short but incredibly massive requirements development phase. One of the issues I’m trying to grapple with is the difference a complex system and a flexible system. I’ve worked in internal IT for my entire career. Internal IT usually attempts to make a system that conforms to the specific business rules of the institution. For example, if you were building a billing system, you build a application that bills specifically for the services or products that your company offers. However, this seems to, over time limit the usability of your systems. As your business changes and grows, the system tends to become less and less relevant to your needs. This leads to more and more patches to your system, which as all of us programmers know, eventually leads to an unsupportable and rigid system.
The other approach I’ve tried for is a flexible architecture that better allows for changes to the business rules. This is the supposed blessing of OOP so that methods can be expanded and changed without modifying the original code therefore keeping changes isolated to the specific processes that need changes. This has worked fairly well. However, the drawback seems to be that the architecture becomes more complex, requiring more time to implement new changes. This is the contrast between the managed and hacker view of a system.
The method I’m working on takes the notion of a flexible architecture and combines it with a flexible rules system as well. Instead of trying to conform only to the institutions specific business requirements but instead tries to provide options to each business rule so that the institution can change how the system operates without necessitating the need for programmatic changes.
I’ve already discovered what a daunting task this can be. I have developed a strong sympathy for Microsoft system engineers who must design their products for such a multitude of different uses. I can already tell that this can lead to stretching your development time out towards infinity. I don’t know by what criteria to judge a business rule that must be fundamentally fixed and one that should allow user options for future needs.
I’m sure this is just an experience thing, but if anyone has any suggestions, I’m very interested. It will be interesting to see how flexible a system can be made with a tiny number of developers. More soon.