UM, um, I mean UML

I'm taking a little break from Windows Workflow to refresh my knowledge of UML and Use Cases. To tell the truth, I never really bought into the whole use case stuff at my previous job. I can give a hundred excuses, all valid of course, for why I didn't believe in UML, but it was mainly because I didn't see my customers buying into the process of software development. They wanted the software. They wanted it now. They didn't want to do any work. Whatever tools we used, whatever diagrams and documentation we drew up, was for our own purposes. They never saw the use in it. By the time the diagrams were done, there was a new crisis du jour, and the last project was already passe.

But I was in a meeting with a new client last week, and one of the reasons I was being brought in to help with this project was to help build an industry standard set of requirement documents which could be handed off to the developers, whether it be my team, or someone else. I was there to do the architecture.

And on the way home that night, it hit me. I might not be there in six months to answer a developer's questions on what was needed. And they might take my name in vain. And they might say that I was incompetent. I can't afford that.

So I picked up my UML book this morning and started re-reading. Realistically, most of the stuff I already knew, but I had never formalized the terminology. I have never put UML / Use Cases on my personal resume because I lacked this formal experience with the process. So with the goal of not looking incompetent, and knowing that I would immediately apply this knowledge to my current daily responsibilities, I am digging in and now seeing the positive side of learning something that I consider 'non-technical'.

In fact, after reading the first 5 chapters this morning, I'm convinced that I can give this book to a project manager I work with, and that with both of us using this style my consitently, we will be better able to understand each other.

Who da thunk it?