Software is nothing but design(agilefocus.com)
agilefocus.com
Software is nothing but design
http://agilefocus.com/2009/09/14/the-myth-of-undesigned/
6 comments
I think you misunderstood what I meant. That's my, fault, though; the bit about software being pure design wasn't my main point there, so I kept it very short. Plus, people use the word design to mean a zillion things. I'm using the word in its broadest sense.
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!
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!
Using the word 'blueprint' is a bit deceptive. Source code is not a blueprint, because it is the end result. A blueprint provides all the information we need to build the house, but we can't live in a blueprint (i.e. a blueprint does not fulfil the same needs as an actual house, even though they describe the same thing). We can 'validate' our (now-built) house against our blueprint using a tape measure and a spirit level.
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.
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.
Source code is in fact not the end result.
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.
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.
The point made in this article is associated with Jack Reeves' classic 1992 essay on source code as design.
http://www.developerdotstar.com/mag/articles/reeves_design.h...
http://www.developerdotstar.com/mag/articles/reeves_design.h...
Faantastic. Thanks for that link; I had never read this.
This is a really good point.
"Show me the code" -- Linus
I wish I could upvote this twice.
"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.
"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.
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.)