"How can I do my design when I haven't written the (expletive deleted) code yet?" a former colleague yelled quite irately as I passed by a manager's office. Now I know Joe. Yes, sometimes he would start out coding and end up with some useless methods and classes. But Joe always had an idea of his code's basic structure. What Joe meant to say was that he could not write the detailed documentation of his design because he hadn't worked out all the details yet.
Unfortunately, many developers look at modeling the way Joe looked at design -- as a documentation step to be completed rather than something that helps the goal of producing properly executing code quickly and efficiently.
Modeling helps developers visualize the structure, interactions, and behavior of the system they are building (NB: I used the plural because developers seldom work alone. One must be able to communicate one's ideas; more on that in another article).
In fact, in a 2008 survey by Scott Ambler found that the vast majority of developers used high level diagrams. From my own practice, I'm assuming that the majority use class diagrams to define structure. I'll bet that a fair number of developers use some variation of sequence diagrams when discussing interactions as well. Here is my point: If you are already using these two common diagrams, why not capture the artifacts in a tool rather than on a white board? Doing so makes the artifacts reusable and captures the design rationale for the rest of the team (including reviewers and maintainers).
Bottom line: if Joe had captured his thoughts in a model, he wouldn't have had the scream match with his boss. He might even still be working there.
No comments:
Post a Comment