See Vs Say
In the discussion TheSourceCodeIsTheDesign, two key notions came up that brought things together for me:
- Heard from TrygveReenskaug, "Modeling is how you write down everything that you want to say that you can't say in the source code. There shouldn't be anything that you want to say that can't be put in the source code.
- From MichaelFeathers: "I think that they would be the same. However, the development environments would generate UML for you on the fly to give you a concise high level view of your source. To me, this seems more important than generating code from models."
To me, what is most important at any moment in time is what the program is. I'm trying to maintain it or evolve it. The only way I have available to say what the program is is the source code.
However, the source code isn't the only way to see what the program is. ExtremeProgramming uses programmer knowledge, expressed through CRC cards, to see some of what the program is. Often we can show with a few cards what would take a long time to browse out.
- KentBeck seems to be able to browse out the essence of a huge amount of code in very little time. I believe that WardCunningham can do it also. They must be smarter than I am: it's much more difficult for me, and for some folks I hang around with.
On a large enough project, or a quiet enough day, there may not be anyone around who knows enough to take you through the cards. On those days, it would be really neat if there were a videotape of the last CRC session ... or, wait, maybe a simple MicroUml diagram with the same information.
Seeing isn't the same as saying, and both are important. --RonJeffries
Re: There should'nt be anything you can't put in the source code.
Maybe I am reading too much into this, but there may be many such things.
Extreme examples includes things like distributed algorithms and communication protocols that can be hard to understand even when a human explains them to you. For these things, even textual explanations are not easy to understand, let alone source code.
Usually, the way to understand them is to build models that are rigorously tested using a technique called ModelChecking ("Model" here is in the sense borrowed from logic), or to build explicit proofs, and spend some time studying them.
A less extreme example might be a single object that plays multiple roles in several patterns. No naming scheme alone can capture or adequately explain them all.
But here, CRC cards, UML and the like would be useful. -- AamodSane