Fog Creek Software
Discussion Board




Coding vs. design

This subject came up in a previous topic, so maybe it can be continued in this new thread...

On one hand coding was said to be a straightforward almost routine task that is not difficult (e.g. coding a report on a payroll system).  On the other hand it was said to be highly involved and complex (e.g. 3-d algorithms for graphics, etc.).

Software was contrasted to traditional engineering projects such as design and construction of a building... an ongoing development/feedback/revision effort vs. a one-time build-it-and-they-will-come approach.

To rehash an old saying... the difference between coding and design is greater in the coding phase than it is in design.

I guess it is too obvious to mention that when someone says they are coding what they really are doing is making design decisions followed by implementation and more testing, getting 'in the zone', etc.  Any comments?

anonymous
Friday, November 29, 2002

I sometimes wonder about those analogies to other forms of engineering.  There are too many shoddy roads, apartments, etc, and you'd think that given millenia they'd eventually get it right.  So I have the feeling that there's something wrong with these analogies.

I think "coding" and "design" are arbitrary terms used heavily by IT.  There are so many restrictions by the need to satisfy many masters (deadlines, cost, target market) that we just mentally separate Stuff into discrete things like coding and design.

Is it the difference between strategy and tactics?  Has anyone ever given a non-messy distinction between the two?  Do the effectiveness of tactics give feedback to strategy?

Tj
Friday, November 29, 2002

--------------------------------------------------------
The unique thing about software is that it is infinitely clonable. Once you've written a subroutine, you can call it as often as you want. This means that almost everything we do as software developers is something that has never been done before. This is very different than what construction workers do. Herman the Handyman, who just installed a tile floor for me, has probably installed hundreds of tile floors. He has to keep installing tile floors again and again as long as new tile floors are needed. We in the software industry would have long since written a Tile Floor Template Library (TFTL) and generating new tile floors would be trivial.
http://www.joelonsoftware.com/news/fog0000000337.html
--------------------------------------------------- Joel

I think this sums it up.  All other human endevours have been distinguished by the cost of effort to repeat any activity.  This has lead to the division of labour that is reflected in many of the distinctions between coding and design we now see.

However, this is wrong thinking.  As Joel points out, the model of labour divison just doesn't appy to software.  The current structures are just leading to inefficiency.  The problem is, we still haven't worked out the right way to do it.

Ged Byrne
Friday, November 29, 2002

Almost all software development is complex. It's not just obviously technical fields such as 3D.

The complexity lies in perceiving the true relationships between entities, and then in resolving the resulting complexity to make the product simple for users. In most fields, this perception and resolution of compexity has never been done before, because humans can implicitly accommodate the resulting nuances. Algorithms can't, and that's why good programmers are needed.

The term "coder" is actually part of a dismissive attitude towards the role and contribution of software designers ( aka programmers. ) If you watch, you will see that it's mainly used by non-programmers. The use of the term is meant to convey that the work of software designers is simply the production of the code, and that there's nothing to that part of it.

Software designers tend to use other terms to describe themselves.

Must be a manager
Friday, November 29, 2002

I think many terms in tech culture are poorly defined: The coder/design confusion you cite is just another.

Consider the hacker/cracker confusion. I personally frequently distinguish between software being easy to *use* and easy to *learn*. Other fields, such as construction, have been around longer and the definitions are clear.

There are organizations that ensure that, say, civil engineers are qualified and there is a central authority there: they therefore have some degree of power over the terms they use.

But software is not like that: It's so wild and uncontrolled that almost nothing is standard, and therefore this confusion springs.

Mike Swieton
Friday, November 29, 2002

The only analogy with software development that ever raised either of my eyebrows was when it was compared to gardening. I can't quite remember were it was but the analogy was spot-on, in that it exposed that there's more about craft than there is about engineering in the software field. I wish I could find the reference.

I am one of those rogues that doesn't really believe in "software design" as a separate activity, or as a document, or whatever. I believe the design of a piece of software is implicit from the very first line of code. Coding can't go without design, and design can't go  without coding. Successful designers are those who can code, and successful coders are those who can design. The phrase "coding vs. design" is a contradiction in terms, at least in my philosophy.

Now, a FUNCTIONAL design is a totally different beast altogether. But I don't believe in them either.

-------------------------
But software is not like that: It's so wild and uncontrolled that almost nothing is standard, and therefore this confusion springs.
-------------------------

Mike, could you please elaborate on why you think that software development is "so wild an uncontrolled". I have the feeling you are right, but I would like to hear why you think so.

Beka Pantone
Saturday, November 30, 2002

I consider Coder to be a honorary title. But then again I don't mind to be called a geek or nerd either...

The general misconception is that coding and designing are separate things. They are not. Coding = Designing. The source code is the detailed design. It's the compiler and the linker that actually build the software design. Somebody in an old thread provided this link to an excellent 1992 C++ Journal article explaining the whole issue:

http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

Jan Derk
Saturday, November 30, 2002

Somewhat offtopic but I'll go for it anyway. Ged Byrne reminded us of this article:

http://www.joelonsoftware.com/news/fog0000000337.html

And after reading it again I think I must object.

-------
In software, the boring problems are solved. Everything you do is on the cutting edge by definition. So by definition it is unpredictable. That's why software has more of a science nature than a construction nature.
-------

Oh! really? Is that the reason why many software developers _waste_ a considerable amount of their life writing UI code? Shouldn't UI subsystems be sufficiently sophisticated by now to spare programmers the pain?

I mean, no matter how far we are into the XXI century I keep hearing people complain about how the customer wants "this in red now", or "one more field in this report here", and "this other button in the other tab there". Mindnumbing work that would rather be spent doing something else if you ask me.

Many coding activities are silly repetitive work. When a software developer is doing silly repetitive work there's something very wrong. Alas, many software developers are now busy changing the code of "that" button so they can meet their customer demands by tomorrow, to think of a better approach to the whole UI ordeal.

Of the millions of developers out there, few are truly remarkable, the rest are doing grunt work. Sad as it sounds.

Beka Pantone
Saturday, November 30, 2002

Beka:

What I'm getting at is that there is no meaning to the terms 'coding' and 'design' that is considered standard across all 'coders' and 'designers'. This is because there is zero barrier to entryh to the field.

Now don't get me wrong, I like that. But it means that there is no standard meterstick with which to judge people and their positions. Not to say there should or shouldn't be, only that there isn't.

If I'm a brain surgeon, I've taken tests and gone to school and done a specific set of things and then after I am considered qualified to do a specific job.

But software jobs have no such measurement, so you get people saying they do XYZ, but it doesn't mean XYZ to someone else if you say the same thing.

Mike Swieton
Saturday, November 30, 2002

Beka,

It is true that the majority of programmer are doing grunt work, but the point it that they shouldn't.

With computers people should never have to do grunt work.  It can be avoided.

However, because of the way software is approached, with an imposed, inaccurage, division of labour inspired by construction, the majority of programmers are wasting their time.

Ged Byrne
Monday, December 02, 2002

"many software developers _waste_ a considerable amount of their life writing UI code?"

You're right, I'd much rather be skiing.

"Mindnumbing work that would rather be spent doing something else"

It isn't the "mindnumbing" stuff that takes the time, that is for the most part done by class libraries. Its the out of the ordinary which has to be hand written that takes the time, and that's not mindnumbing its just frustrating.


Monday, December 02, 2002

Some things -are- grunt work, and are recognized as such, with the result that they are pushed into standard libraries.  So you have things like C's stdio.h (actually an interface to the subroutines), Visual Basic's Windows manipulation libraries, java.util, etc.

If these seem too primitive for you now, try going back ten years and writing code.  (grin)  If you then think that software libraries should have matured more than they did in the last ten years, I would plead the following.

Consider a very simple data structure - one that keeps track of multiple instances of other data substructures, all of which are of the same type.  Most programmers will naturally think of arrays first - a contiguous stretch of physical memory, divided into equal sections, each of which contains information on one of the substructures.

But what will you then do with this structure?

- Will its size ever change?
- Will any of its members ever be replaced, or does it stay the same forever?
- Does it need to preserve the order of its members?
- Are new members always added to the end, or could they be inserted into the middle?
- Are members ever removed?  If so, are they always removed from the front, or from the back, or anywhere?
- Do you need to iterate over the members in order?
- Do you need to iterate backwards?
- Do you need to be able to get to the Nth member quickly?
- Do you need to find the index of a particular member quickly?
- Do you need the members to be sorted in some way?
- Do they need to be sorted in multiple ways?
- Do they need to be sorted into general categories according to one criterion, and then sorted within those categories according to another?
- Can this collection contain duplicate members?
- Are members that look alike duplicates?
- Does this collection contain the actual members, or does it contain references to them?
- Can the references be "null"?
- Can this collection be duplicated?  If so, do all its members need to be duplicated as well?
- Can multiple paths of execution access this collection at the same time?
- Should one execution path lock this collection during some operations?  Which operations?
- Should other code or paths of execution be made aware whenever a change occurs?
- What's the most convenient language in which to express this collection's interface, so that other code can use it easily?

Even something as simple as a collection of like data structures requires all of the above questions to be answered (explicitly or implicitly) before its implementation can be selected.  These questions aren't even exhaustive (I think).  Moreover, the questions will have different answers in different valid situations, so there isn't a One Best Collection Implementation.

Naively speaking, there's millions of valid combinations of answers to the questions above, yielding more possible implementations than you would want to put into a software library.  Somewhat less naively, many of the implementations would be very minor variations of each other, and so answering a question is often reduced to flipping a toggle or dial on a complex collection device.  However, that still leaves dozens of major implementations of a simple collection.

And that's just collections.  What about simple graphical interfaces?  Hardware communication?  Signal processing?  Document layout?

In short, software complexity blows up -very- quickly, even for mundane tasks.

Combine this with the vagaries of information dissemination.  Suppose a majority of the implementations implied above have in fact been coded before.  How do you find them?  You'd need a search engine even if you had them all sitting in front of you.  Some of them may even be proprietary and unavailable.  More likely, some of them will be buggy.  This is why NIH is a syndrome.  It's also why it's quite likely that even grunt-work programs require all-new code to be written.

Wouldn't it be nice if there was a way to express a program spec in such a way that a computer program could understand it, and then churn out an implementation in response?

Paul Brinkley
Monday, December 02, 2002

<<The only analogy with software development that ever raised either of my eyebrows was when it was compared to gardening. I can't quite remember were it was but the analogy was spot-on, in that it exposed that there's more about craft than there is about engineering in the software field. I wish I could find the reference.>>

IIRC this is in _The Pragmatic Programmer_ [1], which IMO should be required reading for all programmers. (I think it's around where they discuss refactoring.)

[1] http://www.pragmaticprogrammer.com/

Chris Winters
Monday, December 02, 2002

Chris Winters,

It is indeed. I just checked my dead tree edition, page 184. Beginning of the chapter on Refactoring.

Thanks for reminding us and for giving me a reason to go back to that book. :)

Beka Pantone
Tuesday, December 03, 2002

Ged Byrne,

<<It is true that the majority of programmer are doing grunt work, but the point it that they shouldn't.>>

Indeed, they shouldn't!

As I said: "When a software developer is doing silly repetitive work there's something very wrong."

As my statement above indicates, I wholeheartedly agree with you. However I shift part of the blame back to the software developer, and this is where I partially disagree with what you say here.

<<because of the way software is approached, with an imposed, inaccurate, division of labour inspired by construction, the majority of programmers are wasting their time.>>

I think software developers are to blame for "silly repetitive work". They/We do it in order to get releases out the door. Not all developers out there use their tools for the benefit of automation (automation is what computers are for, after all, as you indicated). Many developers understand their computer as the tool that they type their source code with, and allows them to run a compiler.

I believe that many maladies in the software development profession that we so often complain about, are our fault. And I think that blaming [management/teams/economy/current state of affairs/outsourcing] is doing software developers a very thin service.

A high percentage of software developers worldwide spend their time swimming in a sea of inefficiency.

Beka Pantone
Tuesday, December 03, 2002

"Wouldn't it be nice if there was a way to express a program spec in such a way that a computer program could understand it, and then churn out an implementation in response?"

My first reaction is "Shit no, at least people can apply intelligence to stupid specifications".

My second is "Have a look at formal specification languages. I'm pretty sure that there is/was definitely an interpreter for OBJ, for example."


Tuesday, December 03, 2002

Paul Brinkley,

[on libraries]
<<If these seem too primitive for you now, try going back ten years and writing code.>>

True.

Well, ten years ago I was around, and some things weren't that bad. :)

I'll go back to the GUI issue. (Forgive me for my fixation on GUI subsystems, but I have hated GUI programming for as long as I can remember)

Ten years ago the Amiga was alive and kicking. I remember there was a library that you dropped in your system and allowed all software in that system to have a customizable UI. I remember the first versions of that lib allowed you to skin apps and little else. But as development continued it got pretty sophisticated, allowing you to entirely remodel an app's GUI, even if that app didn't have explicit support for UI customization.

You might think this could be a nightmare in corporate environments today. Having all employees all use a different GUI for MS Word might not be very productive. But if a library like that were to exist today, it would certainly be multiuser (it needs not be a usability nightmare).

What I am getting at is that libs and frameworks for UI construction sure have evolved as you mention. But this evolution has made it easier for developers to write UI code. From the user stand point GUIs haven't really moved about that much. Sure you get plenty of eyecandy today, sure you have dockable windows and customizable toolbars and menus. But applications have to explicitly support/implement these features, thus giving application developers an unecessary pain in the neck and users an inconsistent GUI. The U in GUI has been ignored for decades.

In my opinion if my customer wanted this label in red, or this other field in the on-screen report. He should be able to have it. That is, without me recompiling, or changing a resource, or application meta-data or do anything for that matter.

Beka Pantone
Tuesday, December 03, 2002

*  Recent Topics

*  Fog Creek Home