All too often we come up with the most complex reason for and solution to, a problem. Yet, the obvious solution evades us. I suppose it's our own self-importance that plays a big role in this form of blindness.I suggest:
- If your computer doesn't work, first see if it is plugged in
- If you're overweight, eat less and exercise more
- If you don't want your mother to worry about you, call her once in a while
- And, if you want to develop great software, model reality, not ideal-ality
This obvious-ness that I am alluding to is reality. Rather than accept the world as it really is, we try to idealize it and in doing so model something that does not exist, and therefore provide a solution to a problem that doesn’t exist.
Information in the real world consists of characteristics (data) and behavior (methods) over a period of time. Not just the current characteristics, not just current behavior, but both the characteristics (data) and behavior (methods) as they change over time.
Most of the software I’ve seen only deals with the current characteristics and behavior of a problem domain. Better software I’ve seen deals with characteristics over time, but applied to current behavior. That’s still not reality.Reality demands that you:
- Track the beginning and ending time for an object’s state, not just the time an event took place
- Add an event date to your method calls so you can apply the appropriate behavior to the event
- Keep historical behavior intact in your methods so you can apply the appropriate behavior to the time of an event
Reality: if you model it, you can reproduce the characteristics and behavior as they took place over time.
As a software architect, if you model reality, your software can reproduce what took place, when it took place. You can create a report from 20 years ago as it existed then, or another from a day ago as it exists now. That’s the kind of accuracy and flexibility software consumers are looking for. That is what they expect. And it’s just one real-world model away.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Software Architect Should Know home page