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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 ....... [EMAIL PROTECTED] Unsubscribe ................ http://gamma.ixda.org/unsubscribe List Guidelines ............ http://gamma.ixda.org/guidelines List Help .................. http://gamma.ixda.org/help