I'm entering a new world. I am reading "Agile Software Development" and learning about design patterns and test driven development. What has occurred to me is that just about every Enterprise application has the same basic building blocks: UI, Data, Policy, Security, and Persistence. It is easy to see how to decouple the UI from the rest of the components, but after that things get hazy.
As I understand it, Data, Policy, and Security relate to the behavior of the application. Persistence is the method of storage, and UI is the means of interacting with the application. Data consists of the raw information being dealt with by the application; Policy defines the access and modification--the conditions under which the accessible data can be modified, and the range of modification. Security basically enables and disables elements of policy, in whole or in part.
Can anyone recommend a good "crash course" in how to elegantly decouple these components? I'd like to design my next system so that I can modify security and persistence mediums without interfering with the Data and Policy components. How worried should I be about decoupling Data from Policy? Does anyone have any good examples of decoupling Data and Policy?
I recently had to open a support issue with Installshield over a perceived problem in their software. I was trying to get unique installation text for each SQL Script I was installing, but when I modified the InstallText listed beside each script, all of the script text was updated with my latest entry, instead of just the script I was trying to change.
The CSR wrote that the behavior is by design. He then thanked me for my "patience and understanding."
This was somewhat infuriating because when I'm trying to get something done, I am neither patient nor understanding of other people's incompetently designed software. A few days later, the CSR wrote to say that unless I had anything more to add on this support request, he was going to mark the request as closed. This was even more infuriating. The CSR had already told me that the behavior was by design, which in my mind effectively says "This is how it is, deal with it." thereby closing the support request. I wrote the CSR back and told him as politely as possible how frustrated and angry I was with Installshield for the way this had been handled. He wrote to say that he was bumping the request up the chain to another technician.
When I got the new technician, he started the conversation by giving me a step-by-step list of instructions on how to achieve what I was trying to do. I tested his suggestion, and it worked the first time out of the box. I realized that part of my problem had been a misconception of how InstallShield was designed, but that part of the problem still lied in poor documentation and bad UI in certain places. I wrote back to the new CSR with gladness in my heart, and thanked him for helping me get my issue resolved
It occurred to me what the difference was between the two CSRs. The first CSR confined his comments to the way I was trying to solve my problem. At the end of his "service" I was no closer to having my problem solved than I was when I created the support request to begin with. The second CSR began his conversation with me by first understanding what it is I am trying to do, and then providing me with the steps necessary to do it. In the process I learned much more about how Installshield is designed, how to make other customizations, and how to provide legitimately helpful comments as to why it did not occur to me to do things the way he suggested in the first place; i.e., poor documetation, non-intuitive UI, and poorly though-out default behavior.
The second CSR realized that the how I was trying to accomplish my goal was not as important as what I was trying to accomplish.
This is hilarious.
The above link is now a bad link. Apparently the site owner received an influx of traffic and wasn't happy about it. He left a nasty animation in place of the generally hilarious Windows-to-Linux animation that was there to start with. I'm leaving this blog in place in case the site owner changes his mind.