-------- excerpt --------
Software is the only medium where the construction materials are
entirely the same as the design materials: source code. When a design
engineer works out a complex problem for how a program will work, she
uses source code. When a production engineer later uses that code as
a design document and produces his own, release-quality, shippable
software, he uses source code. In no other medium is this true and it
is this watershed more than any other that defines the post-
industrial era.

Virtually every industrial age product is first designed on paper or
in some other cheap, disposable, high bandwidth, easy-to-iterate
medium. In fact, it is these characteristics of the tools that allow
design to exist at all.
...

Yes, software can be a cheap, disposable, high bandwidth, easy-to-
iterate medium. Advocates of Agile methods would have you believe
that all software is so. If only it were true. ...
------ end excerpt ------

Is this true? I've never heard of software design being done using
code. Yes, I've heard of coding being done very early in a build
process, in the form of proof-of-concept work or prototyping. And
often this code is used all the way to the final product, often
serving as a foundation for the overall architecture. I've also heard
of engineers beginning coding with extremely poor design
documentation, sometimes with no design at all but requirements

But to call that kind of code "design"? When a software engineer
starts coding without a design plan, which happens sometimes, you can
barely call what they are doing design. But he makes it sound like
this is standard practice. I've never heard that before, except maybe
very recently in the context of Agile.

On the other hand, I am aware of tons of ways of designing software
that doesn't involve code at all, even if we don't count critical
user experience design artifacts like wireframes and UI specs.
Software engineers use UML, DB schemas, architecture diagrams, even
old fashioned flowcharts all the time. Even the most disorganized IT
departments I've worked with have lots of non-code design artifacts.
Companies that outsource need to provide thorough design
documentation before engaging a team a continent awat. Hell, even
Agile folks use these design tools sometimes. All of these are
*exactly* the "cheap, disposable, high-bandwidth, easy-to-iterate"
media that Cooper contends that software designers aren't using.

Any thoughts on this? Do such organizations exist, where coding is
done without any non-coded design? Is Cooper trying to talk about
companies that are so profoundly dysfunctional that they don't show
up on my radar? Do such companies exist?

I see where he is going with the essays -- that interaction design
needs to be part of the design process, something I applaud -- but
that doesn't help the fact that he seems to be saying that something
I see every day doesn't exist.

Comments

HI Chris,
Isn't Photoshop just creating "code"?
Whatever you are doing your design in on the virutal engine known as
a computer is in the end creating code, no?

That was where I went w/ it anyway.

What I think is the problem with Interaction Design which is
intrinsically related to Coopers argument but from a more semantic
side is that "interaction design" actually is the only design
medium that doesn't require FORM at all. It is behavioral and
requires "formational" (I'm making this up) design disciplines to
bring it to life. One such discipline is UI Design/Engineering.

Another way to interpret what Alan is talking about is to think about
his audience. It seems he is speaking to Designer/Developer types who
do code and design as opposed to "true" interaction designers who
already make the distinction you are making.

David Malouf wrote:
> Whatever you are doing your design in on the virutal engine known as> a computer is in the end creating code, no?>> ...>> Another way to interpret what Alan is talking about is to think about> his audience. It seems he is speaking to Designer/Developer types who> do code and design as opposed to "true" interaction designers who> already make the distinction you are making.

You should read the article again. He is quite clearly saying that
engineers design by writing code rather than by producing abstract
planning artifacts, digital or not. He equates their supposed
technique with an architect designing a building using rocks and
mortar. He really is implying, it seems, that the programming field
is in very sad shape. Inmates indeed.

Our applications are all designed on paper first through deliverables such
as wireframes on the ux side, for example; and various technical documents
on the development side - class diagrams; workflow diagrams; state diagrams;
entity relationship diagrams etc etc. When we encounter solution design
issues where we aren't certain that one piece of technology will work
happily with another to produce a desired result, then we'll often produce a
code-based proof-of-concept, but we don't 'design' the application using
code.

Besides which, our 'design' process involves at least four different
disciplines working together, and only one of those could write code, so
it's hardly a suitable medium for communicating design decisions.

Steve

On 30/10/2007, Christopher Fahey <chris.fahey at behaviordesign.com> wrote:
>>> -------- excerpt --------> Software is the only medium where the construction materials are> entirely the same as the design materials: source code. When a design> engineer works out a complex problem for how a program will work, she> uses source code. When a production engineer later uses that code as> a design document and produces his own, release-quality, shippable> software, he uses source code. In no other medium is this true and it> is this watershed more than any other that defines the post-> industrial era.>> Virtually every industrial age product is first designed on paper or> in some other cheap, disposable, high bandwidth, easy-to-iterate> medium. In fact, it is these characteristics of the tools that allow> design to exist at all.> ...>> Yes, software can be a cheap, disposable, high bandwidth, easy-to-> iterate medium. Advocates of Agile methods would have you believe> that all software is so. If only it were true. ...> ------ end excerpt ------>>----------------------------------------------
Steve 'Doc' Baty B.Sc (Maths), M.EC, MBA
Director, User Experience Strategy
Red Square
P: +612 8289 4930
M: +61 417 061 292

I think you both are missing the bigger point. UX is practices by less
than a 1/4 of total software produced today. If you are already using
UX strategies and processes, Alan ain't speaking to you. You are an
interaction designer of some sort b/c you separate the role of design
from engineering from building. Great!

Alan is calling to task all those programmers who think they design
systems without actually doing real design. It's pretty simple
really.

I think you are getting hung up on the semantics and thus aren't
seeing the forest from the trees. Isn't UML just another
codification? Schematics? Psuedo code? Alan's point is that
"unpredictability" can only be challenged through the rigors of
research methods which he espouses under the title of interaction
design.

(I actually think that his definition of IxD is a tad too broad, but
he and I can get into that in Savannah.)

I found this article an excellent read - almost like a loose
manifesto. I have not read his books but this article has some great
gems.

>> Software is the only medium where the construction materials areentirely the same as the design materials: source code.
For some, as David put it, it is Photoshop or Illustrator, for others
it can be Visio, and even others code

>> Yes, software can be a cheap, disposable, high bandwidth,easy-to-iterate medium. Advocates of Agile methods would have you
believe that all software is so. If only it were true.
The arguments so clearly state some discomfort I feel while trying to
apply Agile practices into small/medium applications.

The interesting thing I get out of the article is making the
distinction between programmers who like to design and programmers
who like to build . Many times in my experience there are different
ego's involved when working on a project sometimes they clash and
it's detrimental to the project. Some programmers have an innate
taste for design and a like to design. If that programmer is stuck
doing assembly code that someone else has designed and he personally
thinks it sucks he's not effective in that role and he may over
design the thing and add things to it that are not designed in an
effort to show off his programming prowess and ideas . If you have a
programmer who is more of a production coder and you give him to many
loose ends to tie up chances are it's too late and he will most
likely solve the problem from a pragmatic programming perspective
instead of a user centric perspective . You have to find a way to
utilize and satisfy each programmers desires and strengths.Aww Hell
I dunno I think Kung Fu is the real path to IxD.....

In Coopers article he seems to "Jump the Shark", (makes assumptions that
have little relevance to most companies I've worked for), when he writes:

"Of course you can see how both of these problems, (engineers don't know
how/can't follow design), would stem from the same root: if a programmer has
never learned to follow a written design, then he would structure his daily
work to do without. He would attempt to do the necessary design himself,
concurrent with the construction effort. *And that is exactly what
programmers at all levels and in all sub-disciplines of computer programming
do*: *they design code at the same time as they build it.* If we could
untangle these two parts of the programming job, we could begin to defeat
the apocalyptic horsemen."

He then goes on to identify two types of engineers which I have always heard
called "Engineers", (Cooper calls them "builders") and "Architects", (Cooper
calls them "designers").

Every place I've worked at/heard of, that was a professional/respectable
software co., not in ultra start up mode, did upfront design, besides
"Architectural Software" design. It seems he is implying that "Interaction
Design" as a profession is some new concept, which few software
engineers/projects have heard of or incorporate.

This seems to be very old news, and not really relevant in todays market, or
do I just work for ultra bleeding edge organizations when it comes to
process? I like Alan's premise of promoting our discipline, but he seems to
be looking from the past, (very far past in SW terms - 10 yrs back or so).

Did anyone else get this from the article?
\

30 Oct 2007 - 12:49pm

dmitryn

2004

Amen Rich.

While reading this article, I've tried very had to understand why Alan
has gone to the lengths of inventing a completely new ontology of
software development to justify his point.

The only reason I can think of is that, to a person who is not
familiar with basic principles of software engineering (e.g. a
business stakeholder), the article might sound like a magical fix for
all the complexity and uncertainty that typically plagues software
development projects. Just "segregate engineers who like to design
software from engineers who like to build software". Preferably build
a wall between them. Sounds easy, doesn't it? ;)

As a counterpoint to notions like this, I highly recommend Fred
Brooks's classic No Silver Bullet paper:

On 10/30/07, Rich Rogan <jrrogan at gmail.com> wrote:
> In Coopers article he seems to "Jump the Shark", (makes assumptions that> have little relevance to most companies I've worked for), when he writes:>> "Of course you can see how both of these problems, (engineers don't know> how/can't follow design), would stem from the same root: if a programmer has> never learned to follow a written design, then he would structure his daily> work to do without. He would attempt to do the necessary design himself,> concurrent with the construction effort. *And that is exactly what> programmers at all levels and in all sub-disciplines of computer programming> do*: *they design code at the same time as they build it.* If we could> untangle these two parts of the programming job, we could begin to defeat> the apocalyptic horsemen.">> He then goes on to identify two types of engineers which I have always heard> called "Engineers", (Cooper calls them "builders") and "Architects", (Cooper> calls them "designers").>> Every place I've worked at/heard of, that was a professional/respectable> software co., not in ultra start up mode, did upfront design, besides> "Architectural Software" design. It seems he is implying that "Interaction> Design" as a profession is some new concept, which few software> engineers/projects have heard of or incorporate.>> This seems to be very old news, and not really relevant in todays market, or> do I just work for ultra bleeding edge organizations when it comes to> process? I like Alan's premise of promoting our discipline, but he seems to> be looking from the past, (very far past in SW terms - 10 yrs back or so).>> Did anyone else get this from the article?> \> ________________________________________________________________> *Come to IxDA Interaction08 | Savannah*> February 8-10, 2008 in Savannah, GA, USA> Register today: http://interaction08.ixda.org/>> ________________________________________________________________> Welcome to the Interaction Design Association (IxDA)!> To post to this list ....... discuss at ixda.org> Unsubscribe ................ http://gamma.ixda.org/unsubscribe> List Guidelines ............ http://gamma.ixda.org/guidelines> List Help .................. http://gamma.ixda.org/help>

30 Oct 2007 - 1:31pm

Katie Albers

2005

As far as I can tell, you're comfortable with Cooper's division of
engineers -- although you're accustomed to different terminology...so
let's pass over that.

It seems that you believe that there once was a tendency for builders
to start building before the underlying work of the designer was in
place, but that that no longer happens in today's good companies. All
I can really say to that is "wow! Have you ever been lucky!"

First of all, keep in mind that for many/most of us, our
understanding of the professional SW world is skewed by the simple
fact that we work with and for companies that are smart enough to
hire us. Thus, they implicitly acknowledge the existence and
importance of IxD.

But it is still very much the case that the work of interaction
design gets relegated to the hands of the "builders" much of the
time, in my experience. Time constraints, resource constraints,
failure to understand that just because the engineer *can* work out a
way to get from point A to point B does not mean it will be a good
way...All these things and so many more frequently mean that the
"design" part just doesn't get done except by default.

On the whole, I think the problem described by Cooper remains...and
has remained through many revisions and definitions of who works on
SW teams and what they do and how they do it. System Analysts -- to
my mind -- are a primary example of the obduracy of the engineering
problem. Many moons ago SAs were the individuals trusted with working
out the people-facing side of an app. Very few of them could code and
they weren't generally encouraged to learn how. Now coding is a
standard requirement for Systems Analysts and we are back to trying
to figure out where to locate the underlying design functions for SW.

Some companies are good at separating and integrating the parts of
the process and others aren't. Interestingly, I've always found
start-ups to be better at it than existing and larger companies.

Katie

At 2:03 PM -0400 10/30/07, Rich Rogan wrote:
>In Coopers article he seems to "Jump the Shark", (makes assumptions that>have little relevance to most companies I've worked for), when he writes:>>"Of course you can see how both of these problems, (engineers don't know>how/can't follow design), would stem from the same root: if a programmer has>never learned to follow a written design, then he would structure his daily>work to do without. He would attempt to do the necessary design himself,>concurrent with the construction effort. *And that is exactly what>programmers at all levels and in all sub-disciplines of computer programming>do*: *they design code at the same time as they build it.* If we could>untangle these two parts of the programming job, we could begin to defeat>the apocalyptic horsemen.">>He then goes on to identify two types of engineers which I have always heard>called "Engineers", (Cooper calls them "builders") and "Architects", (Cooper>calls them "designers").>>Every place I've worked at/heard of, that was a professional/respectable>software co., not in ultra start up mode, did upfront design, besides>"Architectural Software" design. It seems he is implying that "Interaction>Design" as a profession is some new concept, which few software>engineers/projects have heard of or incorporate.>>This seems to be very old news, and not really relevant in todays market, or>do I just work for ultra bleeding edge organizations when it comes to>process? I like Alan's premise of promoting our discipline, but he seems to>be looking from the past, (very far past in SW terms - 10 yrs back or so).>>Did anyone else get this from the article?

When I was a young art director I used to hire folks to operate a camera and record my vision. As I got more experienced, and my budgets grew, I began to hire photographers with great skill and hand over my very vague vision for them to run with. I think any profession can be broken down to 'production' minimums if you want. I know there are lots of architects that do not design buildings so much as execute or manage production drawings. I have worked with developers in both categories.

Mark

On Tuesday, October 30, 2007, at 01:56PM, "Dmitry Nekrasovski" <mail.dmitry at gmail.com> wrote:
>Amen Rich.>>While reading this article, I've tried very had to understand why Alan>has gone to the lengths of inventing a completely new ontology of>software development to justify his point.>>The only reason I can think of is that, to a person who is not>familiar with basic principles of software engineering (e.g. a>business stakeholder), the article might sound like a magical fix for>all the complexity and uncertainty that typically plagues software>development projects. Just "segregate engineers who like to design>software from engineers who like to build software". Preferably build>a wall between them. Sounds easy, doesn't it? ;)>>As a counterpoint to notions like this, I highly recommend Fred>Brooks's classic No Silver Bullet paper:>>http://tinyurl.com/yv8kqj>>Dmitry>>On 10/30/07, Rich Rogan <jrrogan at gmail.com> wrote:>> In Coopers article he seems to "Jump the Shark", (makes assumptions that>> have little relevance to most companies I've worked for), when he writes:>>>> "Of course you can see how both of these problems, (engineers don't know>> how/can't follow design), would stem from the same root: if a programmer has>> never learned to follow a written design, then he would structure his daily>> work to do without. He would attempt to do the necessary design himself,>> concurrent with the construction effort. *And that is exactly what>> programmers at all levels and in all sub-disciplines of computer programming>> do*: *they design code at the same time as they build it.* If we could>> untangle these two parts of the programming job, we could begin to defeat>> the apocalyptic horsemen.">>>> He then goes on to identify two types of engineers which I have always heard>> called "Engineers", (Cooper calls them "builders") and "Architects", (Cooper>> calls them "designers").>>>> Every place I've worked at/heard of, that was a professional/respectable>> software co., not in ultra start up mode, did upfront design, besides>> "Architectural Software" design. It seems he is implying that "Interaction>> Design" as a profession is some new concept, which few software>> engineers/projects have heard of or incorporate.>>>> This seems to be very old news, and not really relevant in todays market, or>> do I just work for ultra bleeding edge organizations when it comes to>> process? I like Alan's premise of promoting our discipline, but he seems to>> be looking from the past, (very far past in SW terms - 10 yrs back or so).>>>> Did anyone else get this from the article?>> \

30 Oct 2007 - 1:50pm

Anne Hjortshoj

2007

IMO, "Design engineer" does not equal "designer" in this article. Cooper is
describing well-designed code, not well-designed interfaces.

I'm confused that his essay is being interpreted as an attack on interaction
design. He states very clearly in his essay that he's not talking about this
-- he's addressing the difference between easy-to-iterate (but invisible to
the user!) "design code" and robust "production code."

2cents,

-Anne

On 10/30/07, Katie Albers <katie at firstthought.com> wrote:
>> As far as I can tell, you're comfortable with Cooper's division of> engineers -- although you're accustomed to different terminology...so> let's pass over that.>> It seems that you believe that there once was a tendency for builders> to start building before the underlying work of the designer was in> place, but that that no longer happens in today's good companies. All> I can really say to that is "wow! Have you ever been lucky!">> First of all, keep in mind that for many/most of us, our> understanding of the professional SW world is skewed by the simple> fact that we work with and for companies that are smart enough to> hire us. Thus, they implicitly acknowledge the existence and> importance of IxD.>> But it is still very much the case that the work of interaction> design gets relegated to the hands of the "builders" much of the> time, in my experience. Time constraints, resource constraints,> failure to understand that just because the engineer *can* work out a> way to get from point A to point B does not mean it will be a good> way...All these things and so many more frequently mean that the> "design" part just doesn't get done except by default.>> On the whole, I think the problem described by Cooper remains...and> has remained through many revisions and definitions of who works on> SW teams and what they do and how they do it. System Analysts -- to> my mind -- are a primary example of the obduracy of the engineering> problem. Many moons ago SAs were the individuals trusted with working> out the people-facing side of an app. Very few of them could code and> they weren't generally encouraged to learn how. Now coding is a> standard requirement for Systems Analysts and we are back to trying> to figure out where to locate the underlying design functions for SW.>> Some companies are good at separating and integrating the parts of> the process and others aren't. Interestingly, I've always found> start-ups to be better at it than existing and larger companies.>> Katie>>>> At 2:03 PM -0400 10/30/07, Rich Rogan wrote:> >In Coopers article he seems to "Jump the Shark", (makes assumptions that> >have little relevance to most companies I've worked for), when he writes:> >> >"Of course you can see how both of these problems, (engineers don't know> >how/can't follow design), would stem from the same root: if a programmer> has> >never learned to follow a written design, then he would structure his> daily> >work to do without. He would attempt to do the necessary design himself,> >concurrent with the construction effort. *And that is exactly what> >programmers at all levels and in all sub-disciplines of computer> programming> >do*: *they design code at the same time as they build it.* If we could> >untangle these two parts of the programming job, we could begin to defeat> >the apocalyptic horsemen."> >> >He then goes on to identify two types of engineers which I have always> heard> >called "Engineers", (Cooper calls them "builders") and "Architects",> (Cooper> >calls them "designers").> >> >Every place I've worked at/heard of, that was a professional/respectable> >software co., not in ultra start up mode, did upfront design, besides> >"Architectural Software" design. It seems he is implying that> "Interaction> >Design" as a profession is some new concept, which few software> >engineers/projects have heard of or incorporate.> >> >This seems to be very old news, and not really relevant in todays market,> or> >do I just work for ultra bleeding edge organizations when it comes to> >process? I like Alan's premise of promoting our discipline, but he seems> to> >be looking from the past, (very far past in SW terms - 10 yrs back or> so).> >> >Did anyone else get this from the article?>> -->> ----------------> Katie Albers>katie at firstthought.com> ________________________________________________________________> *Come to IxDA Interaction08 | Savannah*> February 8-10, 2008 in Savannah, GA, USA> Register today: http://interaction08.ixda.org/>> ________________________________________________________________> Welcome to the Interaction Design Association (IxDA)!> To post to this list ....... discuss at ixda.org> Unsubscribe ................ http://gamma.ixda.org/unsubscribe> List Guidelines ............ http://gamma.ixda.org/guidelines> List Help .................. http://gamma.ixda.org/help>

Note I think Cooper has some great ideas, and has really aided me and this
community, he is not perfect, and this latest article just seems old news,
and of little relevance to my situation.

Regarding Anne's comment: "I'm confused that his essay is being interpreted
as an attack on interaction design."

I don't think anyone writing in this thread feel Cooper is attacking ID,
rather he seems to be rehashing very old "positive" concepts on ID, without
considering massive advances the ID field has experienced in the past 10
years +, (note without a doubt Mr Cooper can take credit for many advances).

His comments seem very relevant if it were say, 1995, but it's 2007 and
there are more involved issues with design and development then development
simply being ignorant of design.
_____________________________________________________________

Regarding Katie's comment:

"It seems that you believe that there once was a tendency for builders to
start building before the underlying work of the designer was in place, but
that that no longer happens in today's good companies."

My point of what troubles IxDA designers, and me in particular, was a little
more nuanced then either above black and white statements. The main issues I
deal with today are not when engineers don't know or can't follow ID design,
but rather when there are many factors in the mix, which necessitate
multi-facteted solutions rather then "all would be good if engineers just
"got" design".

What are some of these factors, Katie does a decent job listing a few, such
as "time constraints", "resource constraints", "engineers design
limitations", etc.

This list goes on and on. Add in lots of business problems that might come
up, these are the issues I deal with every day and need solutions to, as
well as engineers that "get it", "don't get it", "don't want to get it", and
"are trying to compete to get it".

30 Oct 2007 - 3:12pm

Dave Malouf

2005

ACtually Rich, I think you are overreaching the advances of IxD and UX
for most programmers.

Let's give a taste. When I was interviewing for the UX Evangelist
position @ MS I learned a few things about reality.

1. There are some 20-25 million MS developers worldwide. That is ONLY
MS developers. Then there are Java and every other type of developer
out there, right?

2. Compare that to at best the numbers of UX professionals in total
out there. What 100,000 at best! And that number in my mind is so
over-inflated. For example there are 5000 IxD's represented on the
IxDA lists.

3. Almost all of the enterprise work I interact with from my position
at Motorola Enterprise Mobility, I have NEVER interacted with anyone
close to a UX professional. These people are creating systems and
software without any research other than at best business analytics.

4. While there is an increase in designers, there is also an increase
in inmates and I have not seen real proof of the problem resolving
itself in any major way.

5. Even where there ARE UX professionals, I often see them as
tokenized, and disempowered behind engineering focused folks. he who
controls the code, controls output and controls the process.

I don't mean to dismiss people's experiences, but if you are doing
Great, I applaud you. The reality is that the far majority of UX
practitioners are working as non-equals to engineers and that where
they do exist is a far minority to where they don't exist at all.

To your point about "constraints" on engineering ... I find most of
these are excuses derived by engineering as a means of saving their
own ass.

on the flip side, I don't think Alan is a great evangelist for
design. I find that by poking at "the other" he is alienating us
even further. I don't think this tactic is valuable even when the
content is accurate and well intentioned.

But it is always nice to see that there is someone out there that is
kickin' ass for the home team!

Coming from a motion graphics "design" & production background and
being relatively new to the software realm and the concept of IxD .
Which I partially find annoying to have yet another term born into
the world that uses the word "Design" in it and always ends up
getting everyone in trouble. (but that's a different bone to pick)
I'm actually curious if anyone knows of a good software critique
or IxD critique site that can pose examples of contemporary software
and web application IxD that provides semi-objective constructive
criticism for projects? A book even ? Is there a place on this site
I'm missing ? I'm curious to see how contemporary work is judged
and "Graded".. Besides reading the ranting the one line comments of
customers on versiontracker.com. Just to at least try and learn from
examples of what the community considers "Good" and "Bad" design.

I imagine Rogan works for an exceptional company . While I'll just
take comfort that "it" does exist out there somewhere. But up to
this point in my own personal experience. (Which I admit is quite
limited) I have not seen it. I would venture to say that I agree
with David and say Rich's experience would be the exception instead
of the rule ?

I haven't heard of such a resource, but this sounds like a great initiative
we could undertake as an organization: A forum for critiques of our own
output and of products that currently exist.

Now that I think of it, I remember someone posting a link to a Flash movie
of two "design-minded frogs" critiquing a website. Seriously. I'm completely
sober, I swear! :-)

- Nasir

30 Oct 2007 - 4:32pm

Kevin Silver1

2006

Thanks Anne, you hit nail on the head.

This is how I read the article and I can from personal experience
relate to Coopers sentiments. I think there is a distinction between
designing how something should work and then designing how you should
build it. Cooper refers to the latter as Design Engineering. Having
in a former life written multiple lines of code I can in my
experience tell there is a difference between design code and
production code. I've spent a lot of time coding just to figure out
how to build something, which can wind up being unwieldy and not
pretty, but somehow still makes it into production because it works.
Which was always unfortunate.

I am dealing with an interface redesign project that has a code
foundation that wasn't architected--designed. I have seen this in a
lot of projects, especially internal applications that are being
productized. Is Cooper saying forethought in how to build it is just
as important as how it works?

If there is a misnomer with Cooper's article is that he left out the
idea of the software architect which in my mind is equivalent to the
design engineer; the one who figures out how to build it. Once again
I chuckled reading this as I did when I first read Inmates.

As an aside, Dave's comment on form was interesting:

"What I think is the problem with Interaction Design which is
intrinsically related to Coopers argument but from a more semantic
side is that "interaction design" actually is the only design
medium that doesn't require FORM at all. It is behavioral and
requires "formational" (I'm making this up) design disciplines to
bring it to life. One such discipline is UI Design/Engineering."

I don't agree with this fully; it depends on how you define form. I
like to think of IxD's form as an intersection between 5-Dimensions
of a design language and a conversation as described in this diagram
I created: http://www.uxmatters.com/MT/archives/images/silver-ixd-
fig_1.jpg. Don't mean to lead us down the rabbit hole of semantics,
I just think its interesting that form always has to be something
tangible. Again just a thought that is semantical and maybe even
contradictory to my diagram and what I have written in the past.

Kevin

On Oct 30, 2007, at 1:50 PM, Anne Hjortshoj wrote:

> IMO, "Design engineer" does not equal "designer" in this article.> Cooper is> describing well-designed code, not well-designed interfaces.>> I'm confused that his essay is being interpreted as an attack on> interaction> design. He states very clearly in his essay that he's not talking> about this> -- he's addressing the difference between easy-to-iterate (but> invisible to> the user!) "design code" and robust "production code.">> 2cents,>> -Anne>>>> On 10/30/07, Katie Albers <katie at firstthought.com> wrote:>>>> As far as I can tell, you're comfortable with Cooper's division of>> engineers -- although you're accustomed to different terminology...so>> let's pass over that.>>>> It seems that you believe that there once was a tendency for builders>> to start building before the underlying work of the designer was in>> place, but that that no longer happens in today's good companies. All>> I can really say to that is "wow! Have you ever been lucky!">>>> First of all, keep in mind that for many/most of us, our>> understanding of the professional SW world is skewed by the simple>> fact that we work with and for companies that are smart enough to>> hire us. Thus, they implicitly acknowledge the existence and>> importance of IxD.>>>> But it is still very much the case that the work of interaction>> design gets relegated to the hands of the "builders" much of the>> time, in my experience. Time constraints, resource constraints,>> failure to understand that just because the engineer *can* work out a>> way to get from point A to point B does not mean it will be a good>> way...All these things and so many more frequently mean that the>> "design" part just doesn't get done except by default.>>>> On the whole, I think the problem described by Cooper remains...and>> has remained through many revisions and definitions of who works on>> SW teams and what they do and how they do it. System Analysts -- to>> my mind -- are a primary example of the obduracy of the engineering>> problem. Many moons ago SAs were the individuals trusted with working>> out the people-facing side of an app. Very few of them could code and>> they weren't generally encouraged to learn how. Now coding is a>> standard requirement for Systems Analysts and we are back to trying>> to figure out where to locate the underlying design functions for SW.>>>> Some companies are good at separating and integrating the parts of>> the process and others aren't. Interestingly, I've always found>> start-ups to be better at it than existing and larger companies.>>>> Katie>>>>>>>> At 2:03 PM -0400 10/30/07, Rich Rogan wrote:>>> In Coopers article he seems to "Jump the Shark", (makes>>> assumptions that>>> have little relevance to most companies I've worked for), when he>>> writes:>>>>>> "Of course you can see how both of these problems, (engineers>>> don't know>>> how/can't follow design), would stem from the same root: if a>>> programmer>> has>>> never learned to follow a written design, then he would structure>>> his>> daily>>> work to do without. He would attempt to do the necessary design>>> himself,>>> concurrent with the construction effort. *And that is exactly what>>> programmers at all levels and in all sub-disciplines of computer>> programming>>> do*: *they design code at the same time as they build it.* If we>>> could>>> untangle these two parts of the programming job, we could begin>>> to defeat>>> the apocalyptic horsemen.">>>>>> He then goes on to identify two types of engineers which I have>>> always>> heard>>> called "Engineers", (Cooper calls them "builders") and "Architects",>> (Cooper>>> calls them "designers").>>>>>> Every place I've worked at/heard of, that was a professional/>>> respectable>>> software co., not in ultra start up mode, did upfront design,>>> besides>>> "Architectural Software" design. It seems he is implying that>> "Interaction>>> Design" as a profession is some new concept, which few software>>> engineers/projects have heard of or incorporate.>>>>>> This seems to be very old news, and not really relevant in todays>>> market,>> or>>> do I just work for ultra bleeding edge organizations when it>>> comes to>>> process? I like Alan's premise of promoting our discipline, but>>> he seems>> to>>> be looking from the past, (very far past in SW terms - 10 yrs>>> back or>> so).>>>>>> Did anyone else get this from the article?>>>> -->>>> ---------------->> Katie Albers>>katie at firstthought.com>> ________________________________________________________________>> *Come to IxDA Interaction08 | Savannah*>> February 8-10, 2008 in Savannah, GA, USA>> Register today: http://interaction08.ixda.org/>>>> ________________________________________________________________>> Welcome to the Interaction Design Association (IxDA)!>> To post to this list ....... discuss at ixda.org>> Unsubscribe ................ http://gamma.ixda.org/unsubscribe>> List Guidelines ............ http://gamma.ixda.org/guidelines>> List Help .................. http://gamma.ixda.org/help>>>>>> --> Anne Hjortshoj | anne.hj at gmail.com | www.annehj.com> ________________________________________________________________> *Come to IxDA Interaction08 | Savannah*> February 8-10, 2008 in Savannah, GA, USA> Register today: http://interaction08.ixda.org/>> ________________________________________________________________> Welcome to the Interaction Design Association (IxDA)!> To post to this list ....... discuss at ixda.org> Unsubscribe ................ http://gamma.ixda.org/unsubscribe> List Guidelines ............ http://gamma.ixda.org/guidelines> List Help .................. http://gamma.ixda.org/help

On 10/30/07, Nasir Barday <nasir at userlicious.com> wrote:
> I haven't heard of such a resource, but this sounds like a great initiative> we could undertake as an organization: A forum for critiques of our own> output and of products that currently exist.>> Now that I think of it, I remember someone posting a link to a Flash movie> of two "design-minded frogs" critiquing a website. Seriously. I'm completely> sober, I swear! :-)>> - Nasir> ________________________________________________________________> *Come to IxDA Interaction08 | Savannah*> February 8-10, 2008 in Savannah, GA, USA> Register today: http://interaction08.ixda.org/>> ________________________________________________________________> Welcome to the Interaction Design Association (IxDA)!> To post to this list ....... discuss at ixda.org> Unsubscribe ................ http://gamma.ixda.org/unsubscribe> List Guidelines ............ http://gamma.ixda.org/guidelines> List Help .................. http://gamma.ixda.org/help>

We've talked about this on the list before, but as a community we need to
recognize just how many people don't understand that good design starts with
being good anthropologists, etc, etc. Once we come to grips with that
(actually, I think lots of list readers come to grips with that 40 hours a
week...), we've got to do for our processes what we do best: design them!
Every company behaves differently (just like different personas), so while
the idea is the same, we have to tailor our processes for the people we work
with if we want good design to catch on at our clients/companies, e.g.
sometimes paper prototyping just won't work some places. We need to talk
with people outside of just each other-- Joel Spolksy, one of the original
Software Engineering bloggers; Product Developers at Maytag and Caterpillar;
any conference without "Usability," "Design," or "Information Architecture"
in its title :-).

Sure, the article has its problems, but it introduces at least the concept
of IxD to software people. Anyway, just furthering the point that our work
is not nearly as widespread as we might like to believe. We still have a
ways to go before being an IxD immediately gets you numbers at the bar, let
alone booking a paying gig without having to convince people they need you.

Sorry, Chris, lost your original question with the soapboxing. Maybe we can
continue this when Part 2 hits ...

- Nasir

30 Oct 2007 - 11:26pm

Alan Cooper

2004

Kevin, Anne,

Thanks for your comments. I think you get my point. This article has
nothing to do with IxD.

It surprises me immensely to find readers on THIS list missing the
central point of my article. When I refer to "design engineers" I am NOT
referring to designers of human-facing form and behavior. Design
engineers, as you two see, design code, not interaction.

It is similarly important to understand that design engineers are not
better or worse than production engineers. They just have different
goals.

Building software is a larger undertaking than most people give it
credit for. It's large enough to require a LOT of design. The code needs
to be designed just as much as the human face needs to be designed. In
the past, software construction has been hampered by the lack of
human-facing design. Today, we do a much better job of designing the
human face, but all too frequently the human-facing design isn't built
correctly or well because the code is poorly designed, or not designed
at all.

I am sorry now that we decided to publish this article in two parts.
I'll see if I can get the second part posted to this list.

Thanx,
Alan

__________
cooper | Product Design for a Digital World
Alan Cooperalan at cooper.com | www.cooper.com
All information in this message is proprietary & confidential.
"There is no country with a military so powerful, an economy so strong,
and a culture so great that its politicians cannot pull it down." -
Donald Gilbert Carpenter

30 Oct 2007 - 11:32pm

Alan Cooper

2004

Dmitry,

Yes, it is indeed pathetic that I need to "invent a completely new
ontology...to justify [my] point."

Welcome to the terminology hell that is software. You'll notice that I
spend an inordinate amount of words in all of my books and articles
clearing out a semantic space where I can make my points free of
mistaken meanings. You'll also notice, including from this very thread,
just how ineffective it is.

Thanx,
Alan

__________
cooper | Product Design for a Digital World
Alan Cooperalan at cooper.com | www.cooper.com
All information in this message is proprietary & confidential.
"There is no country with a military so powerful, an economy so strong,
and a culture so great that its politicians cannot pull it down." -
Donald Gilbert Carpenter

31 Oct 2007 - 7:55am

Christopher Fahey

2005

> It surprises me immensely to find readers on THIS list missing the> central point of my article. When I refer to "design engineers" I> am NOT> referring to designers of human-facing form and behavior. Design> engineers, as you two see, design code, not interaction.

Heh, it looks like I should have read all the recent messages before
posting my last one. Thanks, Alan, for setting things straight. I was
also surprised at this misreading.

I think part of the problem is that when you argue, essentially, that
"engineers don't use design documentation", this seems so completely
wrong that people are trying to figure out what you really mean.
Engineers *do* make and use design documents -- many of us see them
and use them all the time. My guess is that many people are jumping
to the conclusion that you are talking about *interaction design
documents* because that is a reading that makes more sense to them.
Which of course is not what you wrote at all, but the alternative
interpretation -- that engineers don't produce design documents of
any kind -- is frankly just too preposterous to believe for many of us.

> I am sorry now that we decided to publish this article in two parts.> I'll see if I can get the second part posted to this list.

Completely agree! :-) This is one article that isn't helped by
splitting it in two. I look forward to the rest.

I agree -- I don't see how anyone can interpret his article to be
about how engineers neglect to value *interaction design*. This may
be true, and of course Cooper and others have said precisely this a
thousand time. But that's not what the article is about. In the
article, he is explicitly saying that engineers largely neglect *all
design*, including *designing code*. He says, too, that the engineers
whose personalities lend themselves best to designing code
nonetheless neglect to plan properly, and that they normally just
start writing code from day 1.

> I'm confused that his essay is being interpreted as an attack on> interaction> design. He states very clearly in his essay that he's not talking> about this> -- he's addressing the difference between easy-to-iterate (but> invisible to> the user!) "design code" and robust "production code."

I don't think anyone has said that Cooper is attacking interaction
design. But do I agree, again, that when he says "design" in this
article, he is clearly and explicitly NOT talking about interaction
design. He is talking, at best, about design processes in general,
but also specifically about the design of code.

As seen in "The Inmates are Running the Asylum", Cooper generally
doesn't think that software engineers are fundamentally capable of
interaction design. He implies repeatedly that it's just not in their
nature or character (and I won't agree or disagree with this). And as
seen in this new article, too, Cooper likes to characterize people
into neat personality types -- and the "engineer" type is, to him, a
distinctly different type of person from an "interaction designer".

Based on this, I sincerely doubt that he would ever advocate that any
engineers, even design engineers, should have much of a hand in
designing interactions. He doesn't say they should design
interactions in this article, he advocates specifically against this
in "Inmates". So I wonder why people think he is saying this now in
his article.

My guess is that his larger point is/will be twofold:
1) Engineers barely grasp the idea of design, period, even in the
most general sense of planning before building. We should find the
engineers that do "get it", and cultivate design and planning
processes in them.
2) (in part 2 of the essay, which isn't out yet) Interaction
designers are necessary to help mitigate this fundamental lack of
planning on the part of engineers. IDs working with design engineers,
who in turn work with production engineers. That's the solution.

I think people, including me, are reading ahead a little bit by
inferring that Cooper is beating on a dead horse by saying that
Interaction Design Is Important and People Are Neglecting It. What's
weird to me is that he is painting software engineering as a
profession as even more fundamentally dysfunctional than he ever has
before.

Welcome to the terminology hell that is software.
Cooper's terminology here stems from the practice of architecture
(buildings) - where architects "design" buildings and engineers
contribute to the "design" by defining how the building will stand.
Foster Partners (http://www.fosterandpartners.com) do an exceptional
job on many of their projects.
Heck, my friend's boss is just starting to accept that she's a
"User Experience Designer" and not "The Usability Person"
One of the key problems with both UX and IxD is that they have very
strong non-software and non-web applications. Aren't Advertising or
Retail or even Restaurateurs UX Professionals or IxD Professionals?
It's the appropriation of these terms by an industry or category
which reduce credibility. Usability is an aspect of UX, however not
the only one.
Even the very word Design gets defined differently depending on your
practice. Take Art for example: I say Folk Art, you say Art, she says
Martha Stewart.

Has IxDA or any other organization ever taken a survey of SW company
knowledge of/integration with/dependence on Interaction design, (something
like rising up the knowledge pyramid)?

Maybe I have been (very) lucky working for companies where almost all of
them had some idea of the value of upfront user empathetic design, which
aided, (to a greater or lesser degree), the entire SW development life
cycle.

Of course there are places which put lip service only on design, and there
are methodologies that "forgot" upfront design has value, (anybody really
read the book on scrum?).

It is my belief that a critical mass of SW companies seriously consider IxDA
when thinking about SW projects, (maybe they act on this, maybe they don't,
maybe they pay lip service). Is this others experiences?

In terms of professional integration, where are we on the "J" curve? I
believe we're in the 2nd stage where acceleration is continuing, but
velocity may have peaked.

On 10/31/07, Alan Cooper <Alan at cooper.com> wrote:
>> Dmitry,>> Yes, it is indeed pathetic that I need to "invent a completely new> ontology...to justify [my] point.">> Welcome to the terminology hell that is software. You'll notice that I> spend an inordinate amount of words in all of my books and articles> clearing out a semantic space where I can make my points free of> mistaken meanings. You'll also notice, including from this very thread,> just how ineffective it is.>> Thanx,> Alan>> __________> cooper | Product Design for a Digital World> Alan Cooper>alan at cooper.com | www.cooper.com> All information in this message is proprietary & confidential.> "There is no country with a military so powerful, an economy so strong,> and a culture so great that its politicians cannot pull it down." -> Donald Gilbert Carpenter>> -----Original Message-----> From: discuss-bounces at lists.interactiondesigners.com> [mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of> Dmitry Nekrasovski> Sent: Tuesday, October 30, 2007 11:49 AM> To: Rich Rogan> Cc: discuss at ixda.org> Subject: Re: [IxDA Discuss] Alan Cooper on Software Design: Code=Design?>> Amen Rich.>> While reading this article, I've tried very had to understand why Alan> has gone to the lengths of inventing a completely new ontology of> software development to justify his point.>> The only reason I can think of is that, to a person who is not> familiar with basic principles of software engineering (e.g. a> business stakeholder), the article might sound like a magical fix for> all the complexity and uncertainty that typically plagues software> development projects. Just "segregate engineers who like to design> software from engineers who like to build software". Preferably build> a wall between them. Sounds easy, doesn't it? ;)>> As a counterpoint to notions like this, I highly recommend Fred> Brooks's classic No Silver Bullet paper:>>http://tinyurl.com/yv8kqj>> Dmitry>> On 10/30/07, Rich Rogan <jrrogan at gmail.com> wrote:> > In Coopers article he seems to "Jump the Shark", (makes assumptions> that> > have little relevance to most companies I've worked for), when he> writes:> >> > "Of course you can see how both of these problems, (engineers don't> know> > how/can't follow design), would stem from the same root: if a> programmer has> > never learned to follow a written design, then he would structure his> daily> > work to do without. He would attempt to do the necessary design> himself,> > concurrent with the construction effort. *And that is exactly what> > programmers at all levels and in all sub-disciplines of computer> programming> > do*: *they design code at the same time as they build it.* If we could> > untangle these two parts of the programming job, we could begin to> defeat> > the apocalyptic horsemen."> >> > He then goes on to identify two types of engineers which I have always> heard> > called "Engineers", (Cooper calls them "builders") and "Architects",> (Cooper> > calls them "designers").> >> > Every place I've worked at/heard of, that was a> professional/respectable> > software co., not in ultra start up mode, did upfront design, besides> > "Architectural Software" design. It seems he is implying that> "Interaction> > Design" as a profession is some new concept, which few software> > engineers/projects have heard of or incorporate.> >> > This seems to be very old news, and not really relevant in todays> market, or> > do I just work for ultra bleeding edge organizations when it comes to> > process? I like Alan's premise of promoting our discipline, but he> seems to> > be looking from the past, (very far past in SW terms - 10 yrs back or> so).> >> > Did anyone else get this from the article?> > \> > ________________________________________________________________> > *Come to IxDA Interaction08 | Savannah*> > February 8-10, 2008 in Savannah, GA, USA> > Register today: http://interaction08.ixda.org/> >> > ________________________________________________________________> > Welcome to the Interaction Design Association (IxDA)!> > To post to this list ....... discuss at ixda.org> > Unsubscribe ................ http://gamma.ixda.org/unsubscribe> > List Guidelines ............ http://gamma.ixda.org/guidelines> > List Help .................. http://gamma.ixda.org/help> >> ________________________________________________________________> *Come to IxDA Interaction08 | Savannah*> February 8-10, 2008 in Savannah, GA, USA> Register today: http://interaction08.ixda.org/>> ________________________________________________________________> Welcome to the Interaction Design Association (IxDA)!> To post to this list ....... discuss at ixda.org> Unsubscribe ................ http://gamma.ixda.org/unsubscribe> List Guidelines ............ http://gamma.ixda.org/guidelines> List Help .................. http://gamma.ixda.org/help> ________________________________________________________________> *Come to IxDA Interaction08 | Savannah*> February 8-10, 2008 in Savannah, GA, USA> Register today: http://interaction08.ixda.org/>> ________________________________________________________________> Welcome to the Interaction Design Association (IxDA)!> To post to this list ....... discuss at ixda.org> Unsubscribe ................ http://gamma.ixda.org/unsubscribe> List Guidelines ............ http://gamma.ixda.org/guidelines> List Help .................. http://gamma.ixda.org/help>

31 Oct 2007 - 8:28am

Mark Schraad

2006

What might have made this simpler (and I am clearly skating ourside of my lane here) is to not use the word design. Obviously it fits... but using names for stages such as developing a code strategy, designing the code system, and finally the implementation (or production) of final code - would communicate precisely what was intended. I would be interested to hear how the dev crowd, particularly in the agile world respond to this.

The other thing that Alan should probably note is that there is an over arching reaction to his writing based upon the dialog between developers and IX designers. While the 'Inmates' metaphor certainly got peoples attention, there is considerable scaring amongst them. The mere mention of 'inmates' on some of the discussion boards brings out immediate &%#(*@.

Mark

On Wednesday, October 31, 2007, at 10:15AM, "Christopher Fahey" <chris.fahey at behaviordesign.com> wrote:
>> IMO, "Design engineer" does not equal "designer" in this article.>> Cooper is>> describing well-designed code, not well-designed interfaces.>>I agree -- I don't see how anyone can interpret his article to be>about how engineers neglect to value *interaction design*. This may>be true, and of course Cooper and others have said precisely this a>thousand time. But that's not what the article is about. In the>article, he is explicitly saying that engineers largely neglect *all>design*, including *designing code*. He says, too, that the engineers>whose personalities lend themselves best to designing code>nonetheless neglect to plan properly, and that they normally just>start writing code from day 1.>

31 Oct 2007 - 9:06am

Alan Cooper

2004

"The mere mention of 'inmates' on some of the discussion boards brings
out immediate &%#(*@."

Awwwww. <blush>

__________
cooper | Product Design for a Digital World
Alan Cooperalan at cooper.com | www.cooper.com
All information in this message is proprietary & confidential.
"There is no country with a military so powerful, an economy so strong,
and a culture so great that its politicians cannot pull it down." -
Donald Gilbert Carpenter

What might have made this simpler (and I am clearly skating ourside of
my lane here) is to not use the word design. Obviously it fits... but
using names for stages such as developing a code strategy, designing the
code system, and finally the implementation (or production) of final
code - would communicate precisely what was intended. I would be
interested to hear how the dev crowd, particularly in the agile world
respond to this.

The other thing that Alan should probably note is that there is an over
arching reaction to his writing based upon the dialog between developers
and IX designers. While the 'Inmates' metaphor certainly got peoples
attention, there is considerable scaring amongst them. The mere mention
of 'inmates' on some of the discussion boards brings out immediate
&%#(*@.

Mark

On Wednesday, October 31, 2007, at 10:15AM, "Christopher Fahey"
<chris.fahey at behaviordesign.com> wrote:
>> IMO, "Design engineer" does not equal "designer" in this article.>> Cooper is>> describing well-designed code, not well-designed interfaces.>>I agree -- I don't see how anyone can interpret his article to be>about how engineers neglect to value *interaction design*. This may>be true, and of course Cooper and others have said precisely this a>thousand time. But that's not what the article is about. In the>article, he is explicitly saying that engineers largely neglect *all>design*, including *designing code*. He says, too, that the engineers>whose personalities lend themselves best to designing code>nonetheless neglect to plan properly, and that they normally just>start writing code from day 1.>

I find this very interesting as (hold my hands up) I am a developer,
no let me rewrite that, I develop. I come from a computer science
background but it has never sat well with me, I am a people person, I
always found my wife's social anthropology course work far more
interesting. I don't fit Alan's Homo Logicus (see The inmates are
running the asylum) and having read Inmates and now Faces 3. I have
had a new awakening to Software everything I have read makes a lot of
sense and it is true having over 10 years experience in software
development that software is often developed from "designs" such as
UML or flow diagrams which do not relate to IxD.

Building software is logically very complex and these tools help
clarify an understanding of how to build the software.

These tools focus on how to build rather than the bigger picture of
what to build, but in the lack of anything else, they are used by
software developers to decide what to build based on their own
experience self-referential design. Software Architects (again not
IxD) focus on how best to build large complex systems like banking
systems, these architects are the people that try to overcome
implementation barriers by defining software "design patterns" such
as the Model View Controller architecture, or more specific OO idioms
such as Singletons to help overcome barriers and organise code. These
still do not result in a better product for the user but you would be
amazed how much software is developed without even the support of
these implementation designs and I think (if I have understood Alan
correctly) it makes it difficult for software developers to implement
good interaction design from an IxD, if they are not even using good
implementation designs to inform their code decisions.

I also want to add my 10 pence worth on Agile Software development I
recently read an article on how it can be combined with UCD:http://derivadow.com/2007/10/30/making-agile-user-centered/
I personally feel this misses the point. Agile development is a
reactive methodology to trying to design more user focussed software
which is a step forward but Interaction design is a Proactive
methodology and surely as they say in medicine "Prevention is
better than cure".

Unfortunately, there are still many, many developers who have not
even heard of or do not understand the role of IxD and I think
Alan%u2019s quest is far from over. You would be amazed at how many
developers I know who think a Ux professional is simply a User
Interface designer, one quoted to me "The Ux guys are the guys
that use photoshop to make me a pretty button". Also as Alan
points out Software Developers are taught to design their code using
code description languages such as pseudo code, UML etc but not how
use Interaction designs as the blueprint for these implementation
designs.

On 29 Oct 2007, at 21:32, Christopher Fahey wrote:
[snip]
> Is this true? I've never heard of software design being done using> code. Yes, I've heard of coding being done very early in a build> process, in the form of proof-of-concept work or prototyping. And> often this code is used all the way to the final product, often> serving as a foundation for the overall architecture. I've also heard> of engineers beginning coding with extremely poor design> documentation, sometimes with no design at all but requirements>> But to call that kind of code "design"? When a software engineer> starts coding without a design plan, which happens sometimes, you can> barely call what they are doing design. But he makes it sound like> this is standard practice. I've never heard that before, except maybe> very recently in the context of Agile.[snip]

A rather belated response, but the idea of code-as-design isn't a new
one in the software development world. There's a classic series of
essays by Jack Reeves from the early nineties

And, of course, some of the agile methodologies (Which really aren't
that recent. They're mostly codifying techniques that successful
development teams have been using for some time) use this approach
very effectively.