I'd just like to add that this high degree of similarity between a sufficiently detailed design and a sufficiently factored implementation was not nearly so much the case those few decades ago when I started programming.
Languages and programming techniques have been moving toward allowing you to write a program by writing more design-like code while design techniques have been encompassing more of the details that are required when you write the code. There has also been more development of thorough methodologies that encompass both design and coding and these produce even more similarity in design and code when used.
When I've done design that really pushes my abilities, I've longed for a tool that would let me build the framework by typing up some quick class definitions, change panes to see a graphical representation of the resulting relationships, make some changes in that GUI pane, switch back to the first pane and see the classes reflecting the results of my mousing, and continue back and forth like that. I've used some tools that try to come close to that, but none of them did it well enough to be a big pay-off. I always ended up avoiding much of the "help", using them in a "less integrated" manner, and being a bit sad that they were still too awkward or ridgid or whatever such that they became more of a hinderance than a help when I tried to make full use of them.
Note that I agree with your final statement. Even if I had the perfect tool above, I'd only be using that for the design part of the coding. There'd be a line beyond which I'd then be coding and I'd stop using the design tool. Looking back, I'm a bit surprised to realize that C++ appears to me to have done a pretty good (but not perfect) job at effectively separating the design from the code where *.h is nearly all "design" and needn't contain hardly any "code" while *.cpp contains very little "design" (mostly just restatements of chunks of the design that is in the related *.h, and somewhat annoyingly verbose restatements at that).
I do wish C++ allowed the "private:" bits to not be specified in the *.h, however. I also found that enforcing some rules about the order in which you write the different parts of your C++ class definition made it much easier to see the "design" when looking at the *.h. And this all makes me realize that I've not noticed this design/implementation break nearly so much in other languages. And I'll end my musing there (bringing the topic somewhat back to Perl and even to Perl 6, if one is paying proper attention). :)
| [reply] |
Languages and programming techniques have been moving toward allowing you to write a program by writing more design-like code while design techniques have been encompassing more of the details that are required when you write the code.
That's true. I was going to make some kind of comment on that but it was late and I couldn't write it down right :-)
In any case, I'd prefer to have a language that makes it easy to define classes etc, a tool that makes it easy to refactor and some way of visualizing hierarchies etc directly from the code.
My experience with design tools always made me wish I could just type the class interface instead of having to open, drag, click, select and type my way around just to add a method.
| [reply] |
Thanks for the support.
Like all symbolic language, there are inconsistencies in this metaphor. However, I find that sometimes a look outside the immediate surroundings of the topic is necessary. There's a psychological trick here in that removing one's thoughts from the topic at hand for a moment can help one focus more clearly once the mind returns to that track (train metaphor -- watch out). The fact that some semblance can be drawn helps serve the point, but it's far from the only reason for the comparison. I could have just as readily talked about how cute my step-nephew is for a paragraph before moving on to the topic, but I thought the metaphor could serve dual purposes.
It's true that at some point comprehensive software design is almost code and that abstract code is nearly a design. I think there's another point that separates building construction and software development even more, though.
I find that the biggest difference from building construction is because there's so little cost to moving code around. In building construction, it would be wonderful to pull a wall out here and put it back in over there. Unfortunately, there's a lot of physical labor involved, the materials are usually damaged during the remodeling, and the structure may not be as sound afterward. With software, it's much quicker and easier to move whole chunks of code from one place to another, change the interfaces, and generally muck about.
This is in large part because software is abstract, but not necessarily because it is close to the same level of abstraction as the plan. Actually, I'd bet lots of architects are using the 3D building design software on the market to do with virtual copies of buildings what we do with code. Think of it as a visual integrated development environment using pluggable modules to create a value-added design by pointing and clicking, with certain details left to hand-written code(s)...
Now that I've almost choked reading my last buzzword-riddled sentence, let me say that we'll probably never find a metaphor that fits programming better than devising a meal recipe. There are many ways to compare parts of software development to parts of other ventures, but it is so fundamentally different from everything that came before that nothing is particularly adequate in every way. Technical writing can be almost programming, and hardware design can be exactly programming, so those don't serve well as metaphors. A metaphor has to be enough alike while also enough different, and that's a fine line in any case.
Strict research science is still not a preferred metaphor for software development (as a whole) in my mind. Part of the field is certainly science (or close enough to call it that). I see far too much synecdoche surrounding programming, and I'm afraid that's not likely to end soon. Some people mistake programming for a science, while others mistake it for pure math, and others mistake a complex macro-powered server configuration for all of computer programming. This confusion needs to be defeated before the tensions surrounding the field can be released. Programming is all of these things, and none of them is all of programming.
| [reply] |