What is obvious to me now.

Software IS Design:  Part 1

Corinthians I 13:11:
“When I was a child, I talked like a child, I thought like a child, I reasoned like a child. When I became a man, I put childish ways behind me.”

But I have still got so much to learn.

I don’t remember what kind of activity I originally thought programming was, maybe I hadn’t formed an idea. Engineering I think, certainly I did some software engineering at University. I still remember my lecturer, he said if ain’t tested it doesn’t work, and strive for low coupling and high cohesion. That’s about it. Good advice though.

Sometime in my C++ days I learnt from Steve McConnell that software development was definitely a construction process and I learnt a great many other things as well. He also thought low coupling and high cohesion were important and that the most important part of producing software was, well, producing the software, the programming, since it was the only piece guaranteed to be done and probably the only accurate description of the software anyway.

I held this view of building up software from its component pieces for a long time.

The problem with software viewed as construction (still an engineering task really), is it should be more predictable than it is.

  • It normally takes longer and cost more than we thought, unlike houses.
  • We can’t even work out how long it will take, unlike bridges.
  • We don’t actually know in real detail what we will actually get, how it will work and how fast it will run, unlike PCs.
  • And programmers are difficult to manage, they can’t just be replaced with an equally skilled alternative. When things get behind, adding more just seems to make things worse. Not like construction workers at all.

Then after quite a while, I came across software development as a purely design process:

  • Architectural design is design.
  • Functional or detailed design is design.
  • Even Test and Debugging is design.
  • But most importantly Coding is design.

What!

Of course it’s not, we work out all the details in the specification and then get a coder to translate it into code for us. We only need to test it, to fix the mistakes coders make.

Well, no, not quite, not by a long way. We do have a translation process and a build process, in fact we call it a build, it takes a few minutes or perhaps longer and its performed completely automatically by the compiler and linker or ‘ant’ or ‘make’ or the IDE or something like that.

The build process takes an exact set of plans, the source code, and constructs all the pieces into a finished product. As if it was a television or a house, but faster and so cheaply it might as well be free.

I shall not try to convince you that programming is software design directly for now, but show you some of the consequences of thinking of programming as design.

Design

Construction

Design is open ended with only a poorly defined delivery Construction is specific, with a well defined delivery and timescale
Designers are not interchangeable, especially in the middle of the process. Construction equipment and personnel are largely interchangeable at any stage of a project.
Design cannot be automated. Larger parts of construction are routinely automated
Each design will be different from each other design, though there may be similar aspects Each construction will typically be the same as dozens, hundreds even millions of others.
Designers are difficult to manage and can be unpredictable. Construction workers are much easier to manage.
There are not a lot of good designers and they are hard to find. There are many good construction workers and they are significantly easier to get
There can be orders of magnitude difference in the end result from different designers. There will be much less than an order of magnitude in productivity and quality variation in construction workers.
Design is a difficult and error prone process requiring trial and error. Construction is a well understood process, with effective quality control.
Designer love to innovate. Construction workers rarely get a chance to innovate.
A good designer can transform a product, even a company.
e.g. Jonathan Ive
A good construction worker can be relied on to do his bit.

“Learning is not compulsory. Neither is survival.”
W. Edwards Deming

Add Bookmark:  
 

 

 

 

 

 

 

 

 

 

 

 
 
Add to Technorati Favorites
 

… continued in part 2, consequences of Software as Design

Advertisements

~ by icantbelieveit on March 4, 2007.

9 Responses to “What is obvious to me now.”

  1. I think most developers would have realized that the construction metaphor must be used rationally to the extent it is useful and the fact that coding is actually a design activity. Unfortunately, many managers I know do not think the same.

    However, I do not quite understand why you say software is design? Design is just a part of software development, just as requirement specification, an project management etc. It is not software development by itself.

    In addition, when talking about construction, I tend to think it includes both the design/architect phase and building phase, not just building phase. And the design/architect phase demands as much innovation as the design phase of software development. By comparing only the building activity of construction to the design activity of software development, you are comparing orange to apple.

    I had a post about on this topic at my blog.

  2. Jack Reeves also see coding as design. See a series of his essays here.

  3. I’m enjoying your blog, David.

  4. wiwat,

    It was the reprint of Jack Reeves artciles on developer.* that opened my eyes to this view of programming specifically as a design issue. Frequently the software industry is accused of not being rigorous, but from my point of view:

    Computer science is science, but its about the investigation of algorithms, memory models etc etc. and normally happens in universities or large companies. It’s not the development of applications or even languages that happens in the bulk of the software world.

    Software Engineering (and similar labels) is actual engineering. It is a well understood process still trying to escape the remains of its birth. If you look at ALL aspects of software development as a design process then it slots nicely into the engineering world. But as soon as you think of it as a deterministic process your assumptions start to lead you astray.

  5. Buu,

    Um, yes and no.

    I think when you say that for managers the “code is not a mechanistic process” has made some progress in the light of many many experiences. But I still think most people, not just managers are still trying to fit their experiences into the wrong model. That of a production process.

    It is the adherence to the production model (i.e. construction, elaboration etc) that leads people astray.

    I don’t really see requirements as design, though I see how someone might, depends if your big design up front heavy or agile heavy I suppose.

    As far as the other aspects of development are concerned, architectural design, functional specification, coding, test, fix, matinenence its ALL deisgn work. Thinking of it as a design activity rather than a mechanistic activity explains so much that happens in real projects.

    as a previously mentioned luminary said.

    .. to defy the authority of empirical evidence is to disqualify oneself as someone worthy of critical engagement in a dialogue.

    Dalai Lama.

    As I am still seeking enlightenment, I don’t want to do that.

    BTW read your article, its on my stack of stuff to keep (I will issue this and its previous version sometime, as a best of in this blog probably), in the case of UML I have come to think of UML as a good fit for for architects to talk to each other, customers should totally not be expected to interpret UML and for the most part there dosn’t seems to be a good mapping process for actual elaboration/construction/’metaphor of your choice’.

  6. engtech,

    Cool. 🙂

  7. I am glad there are more spreading the paradigm of software != construction! 😉

    http://www.yinsochen.com/blog/2006/12/22/software-is-not-construction/

    http://www.yinsochen.com/blog/2007/01/04/software-is-not-construction-ii/

    Cheers,

    yinso

  8. […] [CODE] What is obvious to me now. (believeitsbetter.wordpress.com, 8 saves) […]

  9. […] are still needed. However, shit happens, live with it. For some reasons why this might be see What is obvious to me now. and The very brilliant, Facts and Fallacies of Software Engineering will be […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

 
%d bloggers like this: