Solve the problem don't create a solution

Problems are strange relatives. They turn up uninvited yet we know that some time or another they will turn up, invited or otherwise. No matter what we do, we can never truly prepare for their arrival, so it's best to deal with them when they turn up (with much courtesy if they are a difficult lot). Luckily for me, it's mostly good as we learn things when we get surprised.

But sometimes, they are a pain. Formalities, sensitivities and the bus load of other past life dramas. If you do decide to lend them a hand (thats more than a ear) you must be prepared to stand by that as you now become part of their system of problems. (see Systemantics)

Everyday or almost every day, we developers (designers, architects if so!), have problems to solve in our systems. We imagine how could we (or they) have designed it better. Often we build a new solution (see hand above) to replace the problem. That's good, but now we know we have promoted the problem (into a solution) so it will come back with more problems. Just be ready for them. Or if we could see a simpler way to solve the problem then do only that and let the problem remain a problem till reaches a point where a real solution is required to fix it and you know you are ready for the slew of new problems that will come with that system. No I am not lazy, I am just old enough to want to live the rest of my life. :)

Hopefully, our work problems vanish when they are solved. On the other hand, the problems or solutions of family and friends mostly only keep coming back.. with a hug ;)

Writing Use Cases

This is an article about writing use cases. Too many people have asked me for a set of rules to work with when dealing use cases. I am so tired of repeating myself that I decided this is the best way forward. For everyone, but mostly for me! As systems differ, so do the rules. As more BAs use them and provide me feedback, we can standardise what is in here.

>> link to document