Software is nothing but design
agilefocus.com
agilefocus.com
Software is far from 100% design. I'd give it 60 or 70% design at best and even then only in the relatively small (though growing) web sphere. Personally, in my career spanning largely web app development, I've found that having an up-front design and simply filling in the back end code is the most pain-free way to go. This still doesn't make the design 100% though. Let's be generous and call the design 90%. There still needs to be working code behind the design.
The other way, as he pointed out is what leads to unusable junk that makes the life of everyone involved (the coder, the designer, the user) painful. When the coder takes it upon himself to make a "temporary" design, it more often than not ends up permanent. This is definitely the worst way to go. I've committed this sin before and learned from it (I'm a terrible designer) but this doesn't have to be the way to go.
If, for some reason, I don't have a designer (and stakeholder!) working closely with me (which is now a warning bell in itself), I can flesh out the main requirements of what needs to be done as far as major features go and design a public api to my software. When I finally get a design, I'll have only the minor features and the integration of my major api calls to do. In this case SaaS is a blessing. (As an added bonus it makes it easy to swap out or rewrite your major features as you hit performance bottlenecks.)
Even if I'm making something with no user interface at all, creating source code is still purely a design activity. The source code doesn't actually do anything; it's a blueprint. When you create the UI, that's designing the UI. When you create the API, that's (as you say) designing the API. Even when you implement the guts, you're still designing them as you go.
I agree with everything else you say, though, especially about the warning bells!
In software, the only analogous process we have is formal specification and mechanical verification.
Just to be entirely clear, code is not a "specification" because to suggest that it is would be like building a full-scale model of a house as a 'blueprint'. If the blueprint is functionally identical to the thing it is describing (i.e. you can live inside the blueprint just as well as you can inside the house it describes), then it's not a "specification" (or a "blueprint") in any useful sense.
So I don't even really have an opinion on the "software is design" explanation. I don't think of software like that, because I don't generally do "exploratory coding". Rather, I'm just objecting to the (often abused) notion of software having anything analogous to a blueprint.
If it were, we wouldn't care so much about non-functional aspects, like spacing, variable and method naming, and code organization. It's a design document. It's special, though, because it is the only design document that the computer can, after processing, understand.
The end result is not the code. It's what happens on people's screens, and in people's worlds after we tell the computer what to do.
http://www.developerdotstar.com/mag/articles/reeves_design.h...
"Design" "Architecture" and "Analysis" have somehow entered this strange place where we talk about them as if they're not related to "real code"
Instead, as the article points out, it's all design. The only difference is which layer of abstraction we're working at. You can make a nice object model by simply kicking out some header files in C, or by declaring some types in OCAML.
We've had so many metaphors -- the factory, the construction site, the military plan -- that we've lost track of just what it is we're doing. And it doesn't help that these buzzwords have generated their own job roles, books, and cultures.