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.
2 responses to “Thoughts on Requirements Development”
It’s always seemed to me like adding abstraction to your design to make it flexible is giving some of the power that the developers have to create the system to the users so they can change it. The tendency is to go from a rigid but easy to use system to a flexible but more difficult to use system. At the other end of the scale, if all your users were programmers they could have ultimate flexibility, and all the complexity that goes with it. In the end I feel like the creation of a flexible but easy to use system is the same problem as making a powerful but easy to use programming environment. Only if you can find the true, permanent bounds of your problem domain in your requirements can you make powerful, permanent reductions in the complexity of your solution.
Sounds great, Dylan. It’s got such a nice zen feeling to it. Welcome to hell, Nathan. When I was working at Baxter, we did design a system that was extremely flexible in many ways. I assumed I knew nothing about the nature of the input, nothing about the nature of the output – hell, I didn’t even know the exact process I was trying to instantiate. Assume you know nothing but a very small core that you can control – and extrapolate the rest.