Discussions

News: Cooper's Manifesto Pushes Developers To Consider A Better Way

  1. Cooper's Manifesto Pushes Developers To Consider A Better Way

    Alan Cooper spoke at last night's "The Future of Software Development" lecture series put on by the Software Development Forum (http://www.sdforum.org/p/l1.asp?pid=546&sid=3) and the Computer History Museum (http://www.computerhistory.com.) Alan is the third speaker in the series after Tim O'Reilly and Grady Booch. If you are in the Silicon Valley consider attending this very good series of public talks.

    For the past 10 years Alan built Cooper Design (http://www.cooper.com) – an agency centered on high technology usability. He is a Microsoft fellow and known widely as the "Father of Visual Basic." Ironically, looking at the usability offered in most VB applications today perhaps Cooper Design is Alan's penance.

    Over the years Alan taught me much about software development processes, software design methodology, and user interaction axioms. For the past year he has been somewhat quiet in the computer industry. He might have simply been responding to the ravages of the recession on Cooper Design. On the other hand it is very much like Alan to go quiet for a while and then burst upwards with new creative energy. When this happens I have been lifted too. Alan's introduced his "Manifesto for Goal-Directed Software Construction".

    Alan began by telling the 150 or so software developers there that he began coding again. Alan is building a new software product and a new kind of software publishing company. It has been 11 years since he last wrote any code. So hearing his contrast of old and current development techniques and tools was very interesting.

    "I recall the old axiom that programming was like digging the Panama Canal with a spoon," Alan said, "And now I find that programming in Windows is like digging the Panama Canal with one tine of a fork." My development tools are equally difficult as the same tools I used a decade ago. In the 1990s I wanted a standard component bus to plug-in my favorite tools into an IDE. I wanted a flexible, open make utility that the industry would get behind to make it easy to build and deploy software. I wanted a visual way to work with objects. Instead I got Visual Studio and NetBeans. Alan pointed out the stagnation in development tools we are suffering through.

    Alan's speech got me to focus on the long term. For example, how do we take the innovations (practices, patterns, and algorithms) that we all recognize are worthwhile and adopt them forever? That is, once something is recognized as worthwhile every future development tool would come with them automatically. In today's environment it is still up to developers to cobble together development tools into useful solutions. On the server side that "cobbling" makes systems brittle and hard to maintain.

    Alan spent the first half of his presentation recounting a litany of business practices that stifle and poison good software development efforts. He challenged us to imagine software development where business managers understand the impact of imposing deadlines that are unlinked to the software development process, where customer input does not dictate software architecture, and where product managers understand and facilitate collaboration between engineer and end-user.

    "In such a world Dilbert comics would not be ironic self references," Alan said. Instead software would be understood to be a new medium that requires new thinking, new business processes and new methodologies. Alan describes the change from old to new in terms of moving from today's Industrial Age to the Information Age. In the Industrial Age coders who are managed by the same processes used to manufacture steel and other real goods develop software. In the Information Age software is created by craftspeople.

    Alan called for a return to software craftsmanship. He noted that the Industrial Age diminished craftsmanship in exchange for high volume production. This has a deleterious effect on software development overall. Alan made the case that software construction needs to be recognized as a noble craft. His remarks were not limited to developers.

    "Imagine if IT success is measured by employee loyalty?" Alan asked.

    The more Alan asked me to imagine the Information Age the more uncomfortable I felt. Alan's words moved me to think about the complex and difficult changes we will need to accomplish. Here in the Silicon Valley, and likely in the rest of the US, the recession is in full swing, we are in the War on Terrorism, and full-scale war in Iraq seems likely. Alan's lecture brought my own fears and frustrations into focus. I am suffering from what Alan describes as an IT environment themed of fear. I wondered if this is the right time to challenge the Industrial Age? It doesn't seem to want to be messed-with right now.

    Alan challenges everyone to think about the ways software is developed today, to shun the management practices held over from the Industrial Age, and to build products that enable end-users to reach their goals.

    Enterprise development still has not finished its work on building commonly understood user interfaces to data and functions. Focusing development community attention on improving our practices, methods and tools seems like an especially good effort right now.

    The agile software development movement (http://www.agilemovement.org/) is a very good example to enterprise developers of a community that formed to challenge the way we develop software.

    Alan pointed us to the Manifesto for Agile Software Development (http://agilemanifesto.org/). The manifesto is a concise statement of values that software developers may adopt by signing-on. Among other things the manifesto says that while there is value in items such as processes and tools, agile developers value individuals and interactions more. The manifesto is a thought-provoking read.

    Alan was so fascinated with the manifesto's approachable style that he put forward his own manifesto for Goal-Directed Software Construction. It goes like this:

    "We are uncovering better ways of serving the highest needs of the real end user by having talented, skilled architects determine how software can best serve the user in collaboration with talented, skilled programmers who determine how the software can best be built. The synergy between these two pragmatic crafts brings value:

    ARCHITECTS AND PROGRAMMERS over engineers and coders
    DOING THE RIGHT THING over doing the thing right
    SERVING THE USER'S GOALS over obeying the user's pathology
    RESPONDING TO REAL NEEDS over creeping featurism
    COLLABORATION BETWEEN PROFESSIONALS over turf battles

    That is, while there is value in the items on the right, we value the items on the left more."

    Manifestos seem especially relevant to software developers today. If not for a new manifesto today what do we have to look forward to? Just the Homeland Security agency's future regulations, more emphasis on EJBs with no real criticism on why we should use them, and consequently a bit of history repeating.

    "The issues are human and not technical," Alan notes about the manifesto's effect on the future of software development. "The solution lies in examining ourselves and not our tools. This is a time to be introspective."

    I find all of this to be fascinating and uplifting.

    -Frank Cohen
    fcohen at pushtotest dot com
    http://www.PushToTest.com

    Threaded Messages (98)

  2. Good post.
    The software industry is still immature and the way software development being done in many places is not a good news.
    Alan is right on the money when he mentions challenging old ways of doing software. May be that's the reason why lot of software out there sucks.
    Developers with strong left-brain tend to pay less attention to these issues.
    I think Frank has a point when he says it's time to reconsider and strive for change in the way we develop and manage software.
    Also, I whole-heartedly agree software development is a craft and no amount of software process can match seasoned developers and dynamic leadership.
    And software industry is always in need of them and no good product will be built without such.
  3. Its comforting to see that the industry is beginning to realize that software offers unique opportunities and management challenges. But the use of a manifesto format is a mistake.

    All we need to do is educate ourselves on the established models for software architectures AND development and how they are *known* to respond to various management and technical decisions -Its computer science but not rocket science and definitely not politics.
    Matt
  4. "principias" - that's such a cool word. Dictionary.com syas:

    prin·cip·i·um ( P ) Pronunciation Key (prn-sp-m)
    n. pl. prin·cip·i·a (--)
    A principle, especially a basic one.

    Also, the term manifesto seems kind of revolutionary in a war like way. I think of Russians running around in a Kafka-esque way. It seems to me that Cooper's Manifesto could also be called a statement of principals.

    -Frank
  5. Frank,
    I was thinking of Newton's Philosophiæ Naturalis Principia Mathematica

    It is the determinism (...the mathematica part) introduced by Newton's Principia that is needed now for software. For the most part it exists, but is not widely known and applied.

    Matt
  6. <Matt Gunter>
    "Its computer science but not rocket science"
    </Matt Gunter>

    Rocket Science isn't so diffcult that you should downgrade Computer Science in comparison (You muppet!). I happen to have experience in both. I hope you stand corrected (F.. muppet!)
  7. You arrogant F**khead.
  8. I understand that these manifestos are for CEO and MBAs, because anyone who really developed software knows how 'non-agile' development methodologies work.

    In reality all software development is agile inside, but pretend not to be in order to satisfy CMM/ISO auditors. Want tons of papers? Get them! We'll sink you in the sea of papers, so you'll never realize what are we really doing :)
  9. Thanks for the intelligence, Frank.

    Alan Cooper is one of the rare true geniuses in the world of software development. This guy really knows what he's talking about. I remember being extremely skeptical at first about his claims, but now I'm swept away by his insightful commentary.

    Everybody should be required to read all his books before entering the field of software. I only wish there are more people like him around.

    Alex
  10. I can't help but expand on the comparison made here between craftsmanship and agile methods. Let's consider them by taking a popular agile methodology as an example.

    Craftsmen sign or mark their work. Sometimes it's a symbol or perhaps just their name. Works that are signed are worth more. XP developers do not "sign" their name on their work. As a matter of fact, it's considered desirable that the author of a particular piece of code cannot be determined. Agile developers "converge" on a common coding style and technique. Craftsmen pride themselves on originality. Note: there is no judgment being made here, just a statement of fact. Craftsmen sign their work while XP developers do not. Craftsmen favor individuality, XP developers favor uniformity. The industrial age favors uniformity as well.

    Craftsmen have tools that are often customized, or at the very least, carefully chosen based on the craftsman's personality and preferences. For example, some musicians have instruments made especially for them. Many wood workers develop jigs designed especially for their craft. Often they don't share these trade secrets with others readily. XP developers use what everybody else on the project is using, again, uniformity. As the industrial age has shown us, uniformity brings cost reductions and XP is keen to this.

    Craftsmen work in individualized work settings. Perhaps it's a workshop with tools positioned just as the craftsman likes. Extreme programmers work in a lab, with generic stations. Craftsmen have particular places where they work best. Extreme programmers don't have a place. They switch seats every so often, similar to how assembly line workers man an assembly line. Just like in assembly lines, extreme programmers are encouraged to man different positions. It's called cross training. Been around since the beginning of the industrial age. Nothing new there.

    Craftsmen are very specialized, often focused on a particular genre or art form. Name a famous craftsman and their specialty will come to mind. Some craftsmen would never allow others to be in their presence for fear of their secrets being copied by others. Van Halen would play with his back facing the audience to protect his individualized fingering technique. "French polishing", a fairly simple technique for finishing furniture, was kept secret to protect it's value and the jobs of the craftsmen. Extreme programmers are discouraged from specialization and work on all parts of a system. Just like assembly line workers, they can be used in any part of the creation of the product. Extreme programmer "A" might be doing UI today, but tomorrow will be working on a back end process. Sometimes it’s even taken further. An extreme programmer, being generic in nature, might be moved to a completely different group and cycled back again.

    Craftsmen apprentice. A master craftsman mentors those he chooses. A junior must approach the master with respect and prove that they have potential. Craftsmen are never forced to mentor someone. Extreme programmers pair constantly. The relationship isn't defined as mentor/mentee. Extreme programmers switch pairs often. Craftsmen take a few select individuals and teach them over time.

    Craftsmen focus on a single task and take however long is needed to produce quality work. Extreme programmers work on an endless stack of cards, some only 2 hours in duration. Extreme programmers context switch at an incredible rate. This is a feature of the industrial age. Channel changing, cell phones, and all that. Extreme programming is similar. One might be finishing a dialog box at 9am, but by 2pm they are coding EJBs.

    Again, no judgment is being made here. Just pointing out that Craftsmanship and software development are a little different, especially when agile methodology is concerned. Agile methods are not a turn away from the industrial age, they are the next phase in the same direction. More impersonal, less freedom, more productivity (velocity is how they put it).

    Taylor Cowan
  11. <Taylor Cowan>
    Craftsmen sign or mark their work. Sometimes it's a symbol or perhaps just their name. Works that are signed are worth more. XP developers do not "sign" their name on their work. As a matter of fact, it's considered desirable that the author of a particular piece of code cannot be determined. Agile developers "converge" on a common coding style and technique. Craftsmen pride themselves on originality. Note: there is no judgment being made here, just a statement of fact. Craftsmen sign their work while XP developers do not. Craftsmen favor individuality, XP developers favor uniformity. The industrial age favors uniformity as well.
    </Cowan>

    I see it differently. XP's primary focus is "build as little as possible and still meet the customer's goals" and "iterate, iterate, iterate!". Each iteration is customized as precisely as possible to that iteration's requirements. Components and reusability are (somewhat) frowned upon - only do it if the requirements make it clear that that's what needed.

    In other words - every XP project is a custom job. There is no assembly line of re-usable parts being assembled into a whole - the whole is the entire point.

    <Cowan>
    Craftsmen have tools that are often customized, or at the very least, carefully chosen based on the craftsman's personality and preferences. For example, some musicians have instruments made especially for them. Many wood workers develop jigs designed especially for their craft. Often they don't share these trade secrets with others readily. XP developers use what everybody else on the project is using, again, uniformity. As the industrial age has shown us, uniformity brings cost reductions and XP is keen to this.
    </Cowan>

    If you look beyond a single XP team, you see exactly the opposite at work. Each XP team does tend to converge towards standard tools and techniques and approaches. But then take one XP team and mix them with another one - chaos! Six guys coding XP-style on a project do indeed share an awful lot, but few XP _teams_ share much between teams.

    <Cowan>
    Craftsmen work in individualized work settings. Perhaps it's a workshop with tools positioned just as the craftsman likes. Extreme programmers work in a lab, with generic stations. Craftsmen have particular places where they work best. Extreme programmers don't have a place. They switch seats every so often, similar to how assembly line workers man an assembly line. Just like in assembly lines, extreme programmers are encouraged to man different positions. It's called cross training. Been around since the beginning of the industrial age. Nothing new there.
    </Cowan>

    Hmmm...see my previous comment. Most programmers who've worked on an XP team for a year, and then move to another team, will find a "generic" station that matches what they used to use.

    <Cowan>
    Craftsmen are very specialized, often focused on a particular genre or art form. [...] Extreme programmers are discouraged from specialization and work on all parts of a system. Just like assembly line workers, they can be used in any part of the creation of the product. Extreme programmer "A" might be doing UI today, but tomorrow will be working on a back end process. Sometimes it?s even taken further. An extreme programmer, being generic in nature, might be moved to a completely different group and cycled back again.
    </Cowan>

    This is indeed the ideal XP environment. And yet I've never seen an XP team that lasted more than 4 months stay this way.

    The reason why is simple: programming skills are not generic and orthagonal to every programming situation. I personally have very in-depth knowledge and experience in server-side solutions. At the same time, it's been convincingly demonostrated that I suck big giant lemons through a straw when it comes to UI programming. My talents, sad to say, do not range the gamut of programming skills. The idea of the "generic programmer, works anywhere on anything anytime" is a great myth of the XP process. Real people who've worked on projects bigger than toys realize that nothing gets done if you don't have specialization.

    <Cowan>
    Craftsmen apprentice. A master craftsman mentors those he chooses. A junior must approach the master with respect and prove that they have potential. Craftsmen are never forced to mentor someone. Extreme programmers pair constantly. The relationship isn't defined as mentor/mentee. Extreme programmers switch pairs often. Craftsmen take a few select individuals and teach them over time.
    </Cowan>

    There may be something to this, but at the same time I'm leery. For example - not all Extreme Programmers pair constantly. Some are cantankerous, some like music blasting in their earphones at 120db, and some just can't focus with someone looking over their shoulder. Sometimes the proven 14 year vet gets tired of getting paired with 25 year olds with a chip on their shoulder - and sometimes the 25 year olds get tired of working with old farts with no imagination. It's a great ideal - but at the same time, pair programming is most often the very first, #1 casualty of on long projects that use XP. Every other aspect may be XP to the core, but quite often pair programming gets chucked as unworkable. Sometimes specialization becomes necessary as the project grows in complexity, sometimes not everyone on the team wants is a "Don't worry, be Happy" kinda person, and sometimes people just want to be left alone for a week.

    <Cowan>
    Again, no judgment is being made here. Just pointing out that Craftsmanship and software development are a little different, especially when agile methodology is concerned. Agile methods are not a turn away from the industrial age, they are the next phase in the same direction. More impersonal, less freedom, more productivity (velocity is how they put it).
    </Cowan>

    I'll agree when a significant number of groups follow agile methods to the letter that you've defined. In the meanwhile, few of us live in the beautiful dream world described by Beck et al.

         -Mike
  12. The difference between our emotional reactions to XP quite amazes me. You raise some valid points, but I vehemently disagree with your conclusion!

    I you've homed in on XP's impact on the "master craftsman". You're correct that XP eliminates many things that a master craftsman might treasure, such the freedom of his own coding style or his own, private tools.

    Many traditional methods make a strong distinction between "craftsman" vs. "apprentice" that places the craftsman in a unique position of power and respect in the workplace. Anything that erodes this would certainly be threatening.

    XP, however, is very humane and very freeing. These "generic" XP programmers aren't helplessly slotted into their tasks, they're choosing their own tasks; they're free to learn about and work on any part of the system they find interesting.

    XP programmers love their work too; in fact, many of the XP practices are driven by a love of quality work. But now, everyone on the team gets input into what that means, rather than just the star programmer.

    XP's style may well be the next phase in the industrial revolution, but if it is, it's undoing the high specialization that disempowers people by associating them with only a narrow part of the process.

    http://www.fastcompany.com/online/28/ge.html

    Michael
  13. Ah -- TSS? I posted once and now there are multiple copies of my message. Is this another site upgrade?
  14. "Alan began by telling the 150 or so software developers there that he began coding again. Alan is building a new software product and a new kind of software publishing company. It has been 11 years since he last wrote any code. So hearing his contrast of old and current development techniques and tools was very interesting. "

    I know little about Alan and his works, but if he hasn't coded in 11 years, maybe we should give him 2 or 3 years before we start hailing him as the next software guru.

    An old mentor of mine many moons ago (in the late 80s) said it well: never take anyone who hasn't written code in more than a year too seriously on their take on software methodologies.

         -Mike
  15. "I know little about Alan and his works, but if he hasn't coded in 11 years, maybe we should give him 2 or 3 years before we start hailing him as the next software guru." -- Mike

    I love software gurus. I love to bask in their radiance. I love being given my professional spirituality from someone who'd rather talk than code. I love us coders being told how to think about development holisticly, and told in a pedantic way managers can understand. I shun thinking for myself and learning from my own environment. The less I know, the more expertly the gurus seem.
  16. Mike wrote:
    >I know little about Alan and his works, but if he hasn't
    >coded in 11 years, maybe we should give him 2 or 3 years
    >before we start hailing him as the next software guru.

    Suppose we're talking about a world famous architect, and if you learn that he hasn't laid a single brick in 11 years. Would you declare him being a questionalbe guru as well? Architects and visionary people (such as Alan Cooper) don't have to do the low level manual work in order to qualify as experts.

    Alex
  17. Alex,

    Your analogy is illogical: architects don't lay bricks.
  18. Your analogy is illogical: architects don't lay bricks.


    Exactly. And software architects don't write code. I used the ludicrous analogy to point the fact that although Cooper didn't write a line of code in 11 years, that does not disqualify him as being a software guru.

    Alex
  19. Exactly. And software architects don't write code.


    The crappy ones don't. I don't know any good software architects who don't validate their designs by coding them. It's tough to execute a UML diagram.

    Jim
  20. The crappy ones don't. I don't know any good software

    >architects who don't validate their designs by coding
    >them. It's tough to execute a UML diagram.

    Ever heard of code generators?

    Alex
  21. <Alex>
    Posted by Alex B 2002-12-10 12:43:45.0.
    >Your analogy is illogical: architects don't lay bricks.

    Exactly. And software architects don't write code. I used the ludicrous analogy to point the fact that although Cooper didn't write a line of code in 11 years, that does not disqualify him as being a software guru.

    <Alex>

    I think it's a mistake to compare traditional architects with software architects. A traditional architect has a giant, well-known constraint hanging over his head: the building has to stay up! To deal with this, materials science has been honed to, well, a science. Materials may improve over time, but ultimately any material can be broken down into density, tensile strength, etc, and the materials chosen heavily constraints the architect.

    In other words - the architect may not lay bricks, but he knows all that a brick is a brick is a brick, and what their intrinsic qualities are.

    The same is _not_ true of software. As I mentioned previously around here somewhere, there is no fundamental underpinnings to constrain us. There's no natural laws, no commodities.

    Programmers constantly choose to constrain themselves - sticking to this standard, this language, this OS, etc. But these constraints are holy voluntary, not natural law. And they're also highly mutable. Once an architect puts a building up, you can't magically change the tensile strength of the girders, or bring the building down with a hand chisel. To do so would require changing fundamental laws. But in a program, you can "magically" change anything at any time to suit. Metaphorically, I can change the tensile strenght of steel if it fits my fancy. And one hokey programmer with little sense can easily bring a program down with the equivalent of a hand chisel in the code.

    An architect from 50 years ago would still get the fundamentals of what holds up a building going up today. A "software architect" from 50 years ago wouldn't have the slightest clue what an RDBMS is, what an Object is, sockets, etc.

        -Mike
  22. <Q>
    . A "software architect" from 50 years ago wouldn't have the slightest clue what an RDBMS is, what an Object is, sockets, etc.

    </Q>
    No need to go that far back. 5 years (or less even) for current technologies. Some even yesterday.
  23. I do not thing that software architecture has changed significantly over decades. From architectural perspective mainframe looks a lot like J2EE.

    I would say that software architects got new “bricks” and “blocks” and tools like “bobcat”.

    A good architect will stay good; especially if he dares to try coding again.
    Alan is right: IT industry pretends to do new things but in reality keeps reinventing the wheel (way too often a square one).
  24. "bobcat"?

    :)
  25. Tomcat = Bobcat.

    I know it. I work with Java since 27 years.
    Bob Farmer
    Extreme Architect
    Agile UML Technologies
  26. <Ignatyev>
    I do not thing that software architecture has changed significantly over decades. From architectural perspective mainframe looks a lot like J2EE.

    I would say that software architects got new “bricks” and “blocks” and tools like “bobcat”.
    </Ignatyev>

    At a very high "architectural" level, a J2EE system may look like a J2EE system. But that's at such a high level as to convey no useful information to anyone.

    Go down to a useful level of architectural information, and you'll find the traditional mainframe solution and J2EE solution to be worlds apart in so many ways that comparisons don't work.

    Just for starters: consider a clustered J2EE solution vs. a mainframe one. Comms between J2EE components in a clustered solution must take network failure into account at a large number of layers. A mainframe solution can take advantage of the more accomodating, "monolithic" environment.

    Example two: VSAM access vs. a replicated RDBMS. A high level architect could wave his wand and dub them equivalent. At a level where people must deal with the two beasties, they are again worlds apart in a real "architectural" sense.

    And to add yet another twist on the broader arguments: a developer today may be asked to create the software equivalent of the Empire State Building. And two years from now that software have the added requirement of having to fly.

    In software, you really can create a empire state building today and make it fly tomorrow. In disciplines such as architecture and engineering, those silly natural laws get in the way.

    Hell, I'm playing Time Pilot '84 on my 500MHz Pentium box with various bells and whistles thanks to MAME. That alone should show how different software is from other disciplines.

    This is not to say that everyone's knowledge in software development goes obsolete every N years. Some concepts and skills are universal. But the devil in building complex systems in the details - and I won't particularly trust an architect or methodology guru who hasn't coded in a decade, because they won't know first-hand the bugaboos and things to avoid in today's technology.

         -Mike
  27. <Me>
    At a very high "architectural" level, a J2EE system may look like a J2EE system. But that's at such a high level as to convey no useful information to anyone.
    </ME>

    Yeep, too many tasks going at once. Should be "a J2EE system may look like a mainframe system".

         -Mike
  28. IMO:
    Tomcat != Bobcat (http://www.bobcat.com/)

    Web application != convenient application for use
    Web application != convenient application to develop
    Web application != only application for all clients
    etc...

    I always consider ArchitectsDontCode as antipattern, but actually I was talking only about lack of ideas.

    BTW: I guess I saw flying " Empire State Building"s. Honestly: they look terrible! And I pray that I never see them again.
  29. We successfully used Bobcat to deploy our web applications in the recent years. For lightweight deployments, we typically use the Mini Track Loader. For clustered deployments with say 50 EJBs+, the All-Wheel Steer Loader is doing a fine job. I have to say, without our bobcats, I would not want to do any web development at all.
  30. Bob Farmer: "We successfully used Bobcat to deploy our web applications in the recent years. For lightweight deployments, we typically use the Mini Track Loader. For clustered deployments with say 50 EJBs+, the All-Wheel Steer Loader is doing a fine job. I have to say, without our bobcats, I would not want to do any web development at all."

    I haven't been able to get bobcat to work with Apache ... even with their 442 Compact Excavator. However, I found that a Caterpillar 580 harvester with Maven+Ant did the trick.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  31. Such large tools. We use Tinker Toys and Legos to build our web sites and applications. It makes them much more flexible, etc. Sure, it takes longer, but they are much more popular with and understood by the younger generation. We thought about Erector Sets but they are just too complicated. Hold on a second ... ["Susie, stop chewing on the round pieces. Billy get the sticks out your nose. Sammy, how many times have I told you the pieces fit together or they don't. So stop crying."] Sorry, gotta go. Uh ... Office crisis.
  32. Cameron,

    we looked into upgrading to the Caterpillar 580 as well, but we just eclipsed, anted and mavenized our little Mini Track Loader and now it runs through the data center like a hot knife thru butter. This actually was so successful that we are looking into selling our good old Wheel Steer Loader. Our new motto: "One bobcat should be enough for everybody" ;)

    Bob
  33. "A traditional architect has a giant, well-known constraint hanging over his head: the building has to stay up!" -- Mike

    Software can crash too.
  34. Software Architects can not be compared with Architects in general. Unlike other engineering fields, in software there is no crisp boundary between architecture and implementation. In real life that boundary is often criss crosssed, because software is a highly iterative non linear process.

    The bottom line is that not all issues and risks can be discovered and assessed during the high level design and architecture phase. I lost count of the number of times I had profound realization about some issues while in the early phase of implementation which will drive me towards a new direction in the design and architecture.

    Few years ago, I turned down a job offer for an "Architect" who will churn out UML diagrams for "Developers" and who is not allowed to write any code.

    Pranab
  35. Exactly. And software architects don't write code.


    I wouldn't like to work with such an "architect" in one team.
  36. Exactly. And software architects don't write code.

    >
    >I wouldn't like to work with such an "architect" in one
    >team.
     
    How about in two teams?

    Alex
  37. Alex,

    tell me, are you an architect who didn't write a piece of code for 10 years? :)

    Seriously, software development is NOT like civil engineering. MBAs don't understand it.
  38. tell me, are you an architect who didn't write a piece of >code for 10 years? :)


    Argyn,

    Tell me, what's so special about writing a piece of code? Is it some mystical ceremony that's supposed to make you see and understand things you wouldn't be able otherwise?

    >Seriously, software development is NOT like civil
    >engineering. MBAs don't understand it.

    Who ever said that software development is like civil engineering?

    Alex
  39. Tell me, what's so special about writing a piece of code? Is it some mystical ceremony that's supposed to make you see and understand things you wouldn't be able otherwise?


    Alex,

    yes, you know. If you don't code, you don't understand certain things. You start to like "methodologies", "processes", "system design documents" and other crap.
  40. yes, you know. If you don't code, you don't understand certain things. You start to like "methodologies", >"processes", "system design documents" and other crap.


    Believe or not but I write code every day and I still like “methodologies” and “processes” and “system design documents”.
    I guess you do not differentiate supporting methodologies and procedures from bureaucratic processes for the sake of processes.

    Greater work(coding) does not mean greater productivity. I suggest reading this book: http://search.barnesandnoble.com/textbooks/booksearch/isbnInquiry.asp?userid=2X524RZD5A&isbn=0471202827 it may give you an idea about non bureaucratic methodologies.


    If you just code, you don't understand certain things :)

    BTW: I am certainly agree that a dog house can be built without any documentation.
  41. I'm surprised I had a pretty controversal reply to this topic and yet no one managed to reply to that at all :)
  42. Exactly. And software architects don't write code.


    Argh. Cooper got it right. Not software, tools or anything software related is our problem. There is no software problem that can't be solved. Instead values and principles that must be considered when writing software are a big issue this days. On this mater, you might consider taking a look at Agile Modeling web site or any other links that the author, Scott Ambler, posted there. I post this reference for two resons:

    1. The values, principles and practices of Agile Modeling are very related to the topic of this thread: "Agile architects are active members of development teams..." are some of his words.

    2. This guy amazes me. I mean he gives away so much extremely valuable software for FREE. All companies get bunches of money for doc/support for their products/services. This guy shares his software dev/architect experience with anyone who want to listen.

    For those who didn't visit, please take a look and you will find very interesting things there.
  43. Ah I found it. Please have a look at the table at the end of this page. It might shed some light on the roles of an architect in a team

    I hope Scott Ambler doesn't mind I point to his words but I think that he deeply touched the topic of this thread long time ago in all the work he has done for Agile Modeling (for which I thank him. He is my analysis/design guru. His work/words aka Agile Modeling web site and related sites were there when I was wondering if I should leave software development for anything more mature).
  44. This "I mean he gives away so much extremely valuable software for FREE" should have read "I mean he gives away so much extremely valuable software analysis/design/development techniques for FREE". Sorry.
  45. Greater work(coding) does not mean greater productivity. I suggest reading this book: http://search.barnesandnoble.com/textbooks/booksearch/isbnInquiry.asp?userid=2X524RZD5A&isbn=0471202827 it may give you an idea about non bureaucratic methodologies.


    Konstantin

    I didn't read that particular book, sorry. But I like agile processes, XP particularly. They all have one thing in common: they understad that software engineering is a very different kind of engineering.

    Recently I developed the sort of allergy to the word "methodology" and "process". When I meet them I get stomack ache and nausea :) The reason is that almost in 100%, when you hear these words it means that there'll be tons of useless papers, endless meetings, UML crap and so on. Then after spending 80% time on this, manager realizes that deadline is 2 months ahead. So, guess what happens! He puts those papers on the shelves, programmers have exrtra hours, everyone forgets about any process whatsoever, you meet your deadline and feel bad. Because, you didn't have enough time to actually program the code, and you are not happy with the quality, but you can't do anything - time's up!

    I don't say that documentation is useless. No. I like documented code, the thing is that there are documents which are needed, and those which are useless. Processes produce 80-90% useless crap to please auditors, to pretend that they are CMM/ISO compliant and so on.
  46. As allways somebody has to exagerate things. Processes don't produce tons of paperwork only if followed step by step with no exact purpose in mind. SOFTWARE NEEDS MODELING NO MATTER IF YOU'RE FOLLOWING A SOFTWARE PROCESS OR NOT !. BUT an Agile Modeling principle states "Model With A Purpose. Many developers worry about whether their artifacts -- such as models, source code, or documents -- are detailed enough or if they are too detailed, or similarly if they are sufficiently accurate. What they're not doing is stepping back and asking why they're creating the artifact in the first place and who they are creating it for." see this If you model to communicate something to others you do it on paper or you do it on a whiteboard or whatever and than print it maybe so the result is paper. But nobody says that you need to model things just because. You model with a purpose. A good developer will allways lay out some diagrams before jumping in code. XP has it's modeling prescriptions whether you're ready to admit it or not. Also XP has a coach. This guy needs to communicate in some way with his team. I doubt that you can communicate an entire design concept through words and all people around understands it in one second, and more, they keep all of it in mind. I can hardly belive that. It's easyer to draw some words, lines and rectangles on a whiteboard so everybody can see it, understand it and discuss it.

    Conclusion:

    - Modeling (business, requirements, architectural) doesn't mean creating tones of paperwork with no purpose. It means creating models, some will end on a paper, depending what you are modeling for, and models always are usefull because you do them for some other reason than following a software process.
    - Software processes are also usefull if used for a purpose, maybe tailored to your project needs. You are a fool if you follow a process only because it says so. Step back and see what helps you from that process and what doesn't. Or create your own. Or don't use one at all. Just don't blame them. They are stupid only if used in a stupid way.

    Argh! sorry for the strong words, if any.
  47. As allways somebody has to exagerate things. Processes don't produce tons of paperwork only if followed step by step with no exact purpose in mind.


    It's a an example of wishful thinking. I'm not talking about theories, my friends. I'm talking about the reality. In reality, in 99% cases when you hear "process/methodologies", it spells troubles, tons of useless docs, meetings, slo-o-ow bureaucratic pace of development and so on.

    In reality, almost no one follows methodologies. They pretend to be following them. Developers simply do their work, they must pretend they are CMM/ISO/RUP, because otherwise they won't get a contract. Developers have fun, methodologies are happy, auditors are satisfied, modelers are employed, customers pick bills :P Everything's alright.
  48. "In reality, almost no one follows methodologies. They pretend to be following them. Developers simply do their work..." -- Argyn

    You well describe the status quo, which lacks awareness of model driven architecture.
  49. <Quote>
    Processes produce 80-90% useless crap to please auditors, to pretend that they are CMM/ISO compliant and so on.
    </Quote>

    Not quite. They don't pretend to be ISO/CMM Compliant. They are that by definition. What they pretend is to be a guarentee of quality.

    Daniel
  50. Tell me, what's so special about writing a piece of

    >>code? Is it some mystical ceremony that's supposed to
    >>make you see and understand things you wouldn't be able
    >>otherwise?
    >
    >Alex,
    >
    >yes, you know. If you don't code, you don't understand
    >certain things. You start to
    >like "methodologies", "processes", "system design
    >documents" and other crap.

    OK. I've recently developed an end-to-end framwerok that is centered around XML Schema documents. Users declare their business (including all the constraints and validations) in an XML Schema (i.e. a repository), and then my framework reads the XML Schema document(s) and generates the whole bloody application. Everything, including the business rules layer, the persistence, the presentation, the logging, the validation etc. layers are generated from the XML Schema.

    That exercise forced me to carefuly examine the process of coding, because my framework had to emulate a bunch of real life programmers. Guess what -- I've discovered that the act of programming is a real trivial exercise. Sure, it is way mystyfied, to impress the common folks, but when you get to the bottom of it, it is rather trivial, meaning you can teach a piece of software to do it.

    So now I have this piece of software that replaces an army of highly paid coders. It generates the whole end-to-end application in less than 20 seconds. To produce the equivalent amount of fully working code, real people would probably require weeks, if not months of uninterrupted coding.

    So my question still is: what's so special about the act of coding? Many people have looked at the code produced by my framework, and weren't able to distinguish whether that code was written by humans, or produced by the machine. Thus, I really don't see anything extraordinary in the ability to produce code.

    Now, the ability to design an application is something totally different, something machines will never be able to approximate.

    Alex
  51. Alex,
    no disrespect intended, but whoever is using your framework is still "coding".
    I understand "coding" as "transforming information from one form to another w/o loss of content".
    You're right that coding - as just the act of transformation - is not not hard. The parts before this _are_ hard. That is requirements gathering, designing the solution etc..
    Your framework still has to have means to express these - for example, I would imagine you have a way of modeling loops - whether explicit or implicit. It's just something you need to model a large number of things.
    I said it before - design _is_ the code. Otherwise how do you know it works? All you can do is run your mental simulations and I haven't yet met anyone who could do them right for arbitrarily complex system.
    Regards,
    Vlad
  52. no disrespect intended, but whoever is using your

    >framework is still "coding".
    >I understand "coding" as "transforming information from
    >one form to another w/o loss of content".

    True. In that respect, Alan Cooper never stopped coding. However, when he says that he hasn't coded in 11 years, he means he hasn't coded using a 3GL.

    >I said it before - design _is_ the code. Otherwise how do
    >you know it works? All you can do is run your mental
    >simulations and I haven't yet met anyone who could do them
    >right for arbitrarily complex system.

    As I've explained above, I don't need to run mental simulations -- I simply push the button and my design gets translated into the executable code. I then play with thus generated/compiled executable code and in that manner am able to determine whether my design works or not. No need for me to do any 3GL coding.

    Alex
  53. I was working with a friend on a system like this 3 years ago, just batting ideas around. I'm glad to know it exists in the world now.

    My issue at the time was usability - code generators can't replace human intervention on usability issues. How do you deal with that?
  54. My issue at the time was usability - code generators can't

    >replace human intervention on usability issues. How do you
    >deal with that?

    I deal with that by buying the analysts/designers more time. Every project comes with limited resources -- limited money supply, limited time supply, limited supply of qualified people. That fact makes designers compromise big time. Because the most unpredictable factor of any software development project is the time required to build the product, everything else gets sacrificed on the altar of code production. "Must start coding now!" is the mantra we hear all too often.

    Because of that, careful upfront analysis gets ditched (unfortunately), and we end up with an unusable product. Now, if we eliminate (or, severely minimize) the anxiety caused by the unpredictability of the duration of the code production, we immediately allow analysts/designers to relax and approach the problem in a more meaningful and productive manner. Like, if we get to the point of realizing that we can generate the bulk of the application code by simply pushing the button, our perspective on the whole process changes drastically.

    When we carefully analyze the issues surrounding the usability of software products, we see that most of these issues boil down to the way users interact with the product. If the interaction is haphazard, confusing, meaningless, aggravating or even menacing, the product will be unusable. If the product is well designed, the interaction with the user will be appropriate, and the product will automatically be usable.

    Of course, the best interaction is the absence of any interaction whatsoever. It is my contention that a really well designed software product will minimize the interaction with the user, thus promoting usability. To illustrate this contention, let me use a simple example:

    Suppose someone gives you the latest CD player, the one that incorporates the latest development in AI. You plop your favorite CD into the player, sit back, and start basking in the crystal clear sounds coming from the speakers. Yes, this player is really excellent. Suddenly, as the end of the first track approaches, you are startled by a mechanical-sounding voice coming out of the speakers; the voice announces:

    "You are nearing the end of track one. Would you like to:
    a) continue listening to the next track?
    b) skip to any of the remaining seven tracks?
    c) stop playing and eject this CD?
    d) hear the weather forecast?"

    Now, would you think that this CD player is very usable or very distractive/annoying?

    Basically, the reason we find products such as CD players usable is because we're not required to interact with them. The same criteria applies to designing software products -- the less interaction, the better.

    However, if you thought that designing a product which offers minimum, or no interaction at all, is an easy thing to do, you are kidding yourself. In my experience, it's the most difficult thing to do, much more difficult than writing a code generator that will read the design and generate/compile the executable code.

    >I was working with a friend on a system like this 3 years
    >ago, just batting ideas around. I'm glad to know it exists
    >in the world now.

    Yeah, 3 years ago was still too early. It's only that with the advent of the XML Schema that we finally have the technology that enables us to accomplish such a feat.

    Alex
  55. Yes, it is a nice vision of creating software that minimizes the interaction between enduser and app.

    Reality is: Everybody screems for customization, individualization, personalization, localization etc.

    What you have to design is a system that provides (e.g. language):
    - Application level defaults
    - Session level defaults
    - Group level defaults
    - User level defaults
    - Request level defaults

    Now, of course, the system needs to keep in mind that all these defaults could be overridden, e.g.
    - User does not want to have default session language, user therefore set a specific language in his profile (that persists). In the next session, he might choose a different language (this time without updating his persistent profile)
    - User might request a page in a specific language (yeah, bad example, but I once was on such a project, no kidding), basically providing the language parm in the post, which should override everything, session settings, user settings, browser settings etc.)

    Other example for customization: All the portal products/projects popping up like jetspeed.

    Keep in mind, that users are crazy. You can establish standards on machines and machine-to-machine communication. When you deal with users, there are no standards. Every user will have different preferences, different abilities and different disabilities. Different planets, different cancers. Admitted, for simple applications, code-generators will definitely work. But you will have a hard time with this kind of "new" and "complex" applications.

    It is little bit like with aspect oriented programming. You can weave in your code aspects for generic concerns like logging, transactions, distribution etc., and this will absolutely boost your productivity, but when it comes down to non-generic, very project-specific requirements, aspects fail.

    I guess, if you want to convince me otherwise, you will have to describe something like the biggest system you created with code generators and the nature of its users.

    -Bob "they called him Bobby" Farmer

    PS: My favourite code generator was "Basic Bear", available on C64 in 1983
  56. Yes, it is a nice vision of creating software that

    >minimizes the interaction between enduser and app.
    >
    >Reality is: Everybody screems for customization,
    >individualization, personalization, localization etc.

    A prudent person would, at this point, stop and ponder -- why does everyone scream for customization etc.?

    Could it be that people are frustrated with the existing products, and are harbouring hopes that by increasing the customizability etc., they might alleviate the feeling of being aggravated by the software?

    Which brings us back to the upfront software design. If we do the upfront analysis/design correctly, I can almost guarantee you that all these screams for customization, individualization, personalization, etc. will calm down.

    >Other example for customization: All the portal
    >products/projects popping up like jetspeed.

    Portals/Jetspeed is a particularly bad example. What portals are trying to do is act as desktop-wannabes. In other words, they attempt to replace the operating system by allowing the users to stay within the browser. So, portals are not a good model of business applications.

    >Keep in mind, that users are crazy. You can establish
    >standards on machines and machine-to-machine
    >communication. When you deal with users, there are no
    >standards. Every user will have different preferences,
    >different abilities and different disabilities. Different
    >planets, different cancers. Admitted, for simple
    >applications, code-generators will definitely work. But
    >you will have a hard time with this kind of "new"
    >and "complex" applications.

    Again, it all boils down to the correct design. With the correct design, you'll end up with a product that is least disruptive, so your users will simply forget about their preferences, and let the product do the work for them. It's the same with any successful product -- we just use it, and most of the time have no preferences. Preferences arise when the product we're using is lousy, so we're trying to tweak it. There is usually no need to tweak a good product (a good example is a CD player, which I've used in another post; a CD player is a well designed product because is delivers its purpose with the least possible amount of interactivity -- it simply plays the music. No interaction, no fuss, no muss. Software products must be designed like that, if we want them to be successfully adopted).

    >It is little bit like with aspect oriented programming.
    >You can weave in your code aspects for generic concerns
    >like logging, transactions, distribution etc., and this
    >will absolutely boost your productivity, but when it comes
    >down to non-generic, very project-specific requirements,
    >aspects fail.

    That, however, does not diminish the fact that using the aspects may have already saved us tons of time upfront.

    >I guess, if you want to convince me otherwise, you will
    >have to describe something like the biggest system you
    >created with code generators and the nature of its users.

    How about we settle for the "my Dad can beat up your Dad" deal?

    Alex
  57. <Alex>
    ...why does everyone scream for customization...
    </Alex>

    You are funny :-)

    <Alex>
    ... I can almost guarantee you that all these screams for customization, individualization, personalization, etc. will calm down...
    </Alex>

    This screams comes from the demand to build products that can be deployed globally. As not all people in the world have the same preferences, you need to consider those screams. In Texas, they really like steak, in India, they really don't. A prudent person would not put a steak on the menu while in India. A stupid person would not put a steak on the menu while in Texas.

    <Alex>
    So, portals are not a good model of business applications.
    </Alex>

    Hm, although I think there are bad portal implementations, I do think portals are an awesome idea. E.g. they allow me to customize what I wanna have on my first page when I logon to my internet banking (Do I really wanna see a list of my last credit card transactions? My account statements? An overview of my accounts?)

    So - portals a particularly bad example? (Go, tell this to Rickard Oberg :)

    I think a CD player is a bad example, since it is oversimplified. Compared to software, the user interface of e.g. amazon.com or whatever interactive site just does not compare to play/stop/pause.

    <Alex>
    ... so your users will simply forget about their preferences ...
    </Alex>

    I'm glad you have customers that adapt their personality to your systems. I never met one of those. Your company sounds like a dream to work for. Do you actually have requirements or do you just design and then require your users to use it?
    It's kind of a Borg-ish approach. Nobody wants to be assimilated, but the heck, when you have no option.

    Yet, with all this being said, I marvel your ideal of simple systems. I guess, Developers always strive to make systems simple, because it is less work to develop. But, darn it, it's the users who make the requirements, it's the users who add the complexities, it's the users who just don't wanna be standardized. Darn you, diversity, you nature of human beings.

    To summarize: Code generation - yes, but only for the repetitive parts of development (e.g. use of Middlegen/XDoclet to generate a data access layer). For the business layer and presentation layer, a code generator can help to build a skeleton, but most of the work I believe must still be done by hand. I know, that you are not agreeing, but I also know, that we are talkin about different kind of systems.
  58. Guys, you've hit the bane of my existence. And both of you are right, to a degree.

    First, good analysis and design (around the user interface) does reduce the need for personalization and customization.

    For me, I always go in and do user analysis, then task analysis based on what those users need to do to get their job done. So, customization is always required. An executive will have access to different functionality than a data entry clerk, we use the same general set of screens, but customize them to the user role a person has, their location, and the proper language (current system we're building has 82,000 users in over 132 countries).

    Personalization is different. A user's ability to set their own preferences makes sense in some cases, others not. If you give users the correct default settings, only 10%-20% go in and actually personalize their interfaces. However, if you do not build that ability, they whine. So, it depends on how much organizational control you have.

    I spend all of my time with users. They're not stupid or crazy, but many are uneducated. And with the advent of the Web, everyone has their favorite user interfaces and pet functionality they want, and it's hard to get them under control a lot of times ("just make it like Yahoo"). I focus on the tasks that need to be supported first, then I architect the interface to support those tasks. That cuts down on a lot of noise. Usability-testing also helps cut down on my opinion vs. your opinion battles.

    But it is never easy.

    Elaine
  59. I spend all of my time with users. They're not stupid or

    >crazy, but many are uneducated. And with the advent of the
    >Web, everyone has their favorite user interfaces and pet
    >functionality they want, and it's hard to get them under
    >control a lot of times ("just make it like Yahoo"). I
    >focus on the tasks that need to be supported first, then I
    >architect the interface to support those tasks. That cuts
    >down on a lot of noise. Usability-testing also helps cut
    >down on my opinion vs. your opinion battles.

    I believe this is wrong. Just because Yahoo is so prominent and popular, doesn't mean that it's necessarily a good role model to follow. Same is with Microsoft on the desktop. Just because Microsoft products are everywhere, doesn't mean we should follow their user interaction paradigms when building desktop products.

    That's why going to the users and asking for what is it that they want is so detrimental. They don't really know what they want. All they know is that they've been abused by lousy software (c.f. Microsoft) for many, many years. They have battle scars to show. But, after banging their heads against the wall for such a long time, they became kind of desensitized, and have by now resigned to the fact that all the software they are forced to use is very abrasive.

    It's like asking a person who's been force fed-junk food for many years: "what kind of food do you like?" Of course, the person will reply: "fried onion rings", or some such nonsense. But it doesn't mean that we're obliged to give them a strict diet of fried onion rings; it is our duty as highly evolved professionals to introduce them to a healthier diet, containing less hydrogenated oils etc.

    Ideally, software product should be dedicated to supporting one clearly defined central task that the user must execute day in, day out. If the product was 'designed' (out of its makers' confusion) to try and fulfill many different, unrelated or barely related roles, it will (naturally) cause a confusion in the user's head. As is to be expected, the user will then start clamoring for more control, for customizability, and so on. That added 'control' serves in the user's mind to shield him/her from the whims of the unpredictable software product. But, of course, it's just an illusion, as no amount of twiddling with the configuration and customization and personalization knobs will make the software behave the way it should, which is simply do the central task. That's why 'featuritis' is such a deadly desease.

    Now, instead of fighting it, you seem to go along with it. No wonder software industry is in such a sorry state today.

    Alex
  60. "I believe this is wrong. Just because Yahoo is so prominent and popular, doesn't mean that it's necessarily a good role model to follow. Same is with Microsoft on the desktop. Just because Microsoft products are everywhere, doesn't mean we should follow their user interaction paradigms when building desktop products."

    Alex, I didn't say it was a good idea. I said it's my job to keep users from doing it. This is the kind of stuff they'll tell developers - "just make it like Excel, just make it like Yahoo." It's my job to say, "No, we're not doing that, we're not discussing that, I want to talk about your business." THEN, I do the interface design, and I do it on my own, not with the users.

    "That's why going to the users and asking for what is it that they want is so detrimental. They don't really know what they want."

    You don't ask them what they want in the interface. You ask them about their business. You study the tasks they do.

    Again, users are not stupid. But they are not technology experts. They are not interface designers. They are smart about their business (hopefully). They are smart about the tasks they perform. That's what I want to get from them, the rest is my job.

    Elaine
  61. Alex, I didn't say it was a good idea. I said it's my job

    >to keep users from doing it. This is the kind of stuff
    >they'll tell developers - "just make it like Excel, just
    >make it like Yahoo." It's my job to say, "No, we're not
    >doing that, we're not discussing that, I want to talk
    >about your business." THEN, I do the interface design, and
    >I do it on my own, not with the users.

    Yes, I know that that's what you're doing. I was just using your comments as a springboard to bring some important points into the discussion. It is very obvious to me that you're on the ball, Elaine:-)

    >You don't ask them what they want in the interface. You
    >ask them about their business. You study the tasks they
    >do.

    Thanks for restating this, Elaine. It is extremely important to realize that business requirements gathering is totally separate and independent from the technology/user interface requirements gathering.

    >Again, users are not stupid. But they are not technology
    >experts. They are not interface designers. They are smart
    >about their business (hopefully). They are smart about the
    >tasks they perform. That's what I want to get from them,
    >the rest is my job.

    See, this is what I call clear thinking. And as soon as we have clear thinking enter the picture, simplicity enters the picture. And then, all of a sudden, we can all sleep soundly at night.

    Alex
  62. Thanks for restating this, Elaine. It is extremely important to realize that business requirements gathering is totally separate and independent from the technology/user interface requirements gathering.


    dream on!

    .
  63. No, Argyn, I do it this way, and in all different companies with abbreviated development schedules and big time to market pressure. In the end, the development cycle is actually shorter. It works, but it takes a paradigm shift for a lot of people.

    And if you don't have management support, forget it. Then, it IS a pipe dream.
  64. This screams comes from the demand to build products that

    >can be deployed globally. As not all people in the world
    >have the same preferences, you need to consider those
    >screams. In Texas, they really like steak, in India, they
    >really don't. A prudent person would not put a steak on
    >the menu while in India. A stupid person would not put a
    >steak on the menu while in Texas.

    Ah, yes, this is where the real problems with software begin. Many people like to take the opportunity, while building a software product, to turn it into a general purpose solution. They want to make it serve all the people in all the countries in the world. They also want to make it serve all kinds of needs at once. That's a noble intention but unfortunately it doesn't work.

    Software only works well if it's been designed to serve a very narrowly delineated problem domain. Typically, a product that's been designed to cover one central task, and maybe several subservient ones, stands a good chance of not being dysfunctional. Anything more than that, and it rapidly becomes unusable (just look at the general purpose crap Microsoft is pushing on us).

    So, if I were you, I would design and build separate products for Texas and India.

    ><Alex>
    >So, portals are not a good model of business applications.
    ></Alex>
    >
    >Hm, although I think there are bad portal implementations,
    >I do think portals are an awesome idea. E.g. they allow me
    >to customize what I wanna have on my first page when I
    >logon to my internet banking (Do I really wanna see a list
    >of my last credit card transactions? My account
    >statements? An overview of my accounts?)
    >
    >So - portals a particularly bad example? (Go, tell this to
    >Rickard Oberg :)

    Sorry, I failed to express myself clearly. I didn't mean to say that portals are not good. I like portals, but what I wanted to say was that portals are actually not business applications. Portals are more akin to operating systems. Same as operating systems are not to be viewed as business applications, we shouldn't view portals as business applications, and shouldn't draw parallels between portals and business applications. In other words, what works for portals cannot be applied to business applications, and vice versa.

    Portals serve to host other business applications, same as operating systems serve to host other business applications. That's why I said that portals are not a good model of business applications.

    >I think a CD player is a bad example, since it is
    >oversimplified. Compared to software, the user interface
    >of e.g. amazon.com or whatever interactive site just does
    >not compare to play/stop/pause.

    Why not? To me, amazon.com should offer similarly simplified interface to their users: browse/select/pay. That's the central task of a typical amazon.com's user. Yes, there are other tasks, but they are not that prominent, so we can make them subservient to the browse/select/pay task (same as the CD player can offer many other interface features, such as random play, programming, fade out, etc., but because they are typically used in no more than 2% or 3% of the cases, they are totally subservient to the play/stop/pause task).

    As some of you already know, what differentiates really good software developer from an average one, is the ability to simplify. This ability is incredibly difficult to master, and only the best experts have it developed to the fullest degree. Without the ability to simplify, software development becomes a nightmarish task. Unsimplified, the product we're developing becomes a freakish bowl of spaghetti code, where steaks get served in India and withdrawn from the menu in Texas.

    ><Alex>
    >... so your users will simply forget about their
    >preferences ...
    ></Alex>
    >
    >I'm glad you have customers that adapt their personality
    >to your systems. I never met one of those. Your company
    >sounds like a dream to work for. Do you actually have
    >requirements or do you just design and then require your
    >users to use it?
    >It's kind of a Borg-ish approach. Nobody wants to be
    >assimilated, but the heck, when you have no option.

    We only have business requirements. We don't have technology requirements. Most companies tend to make the grave mistake of mixing the two. They make the business requirements interchangeable with the technology requirements. All of a sudden, installing the latest release of WebLogic becomes a business issue. That's insane, if you ask me.

    Now, the situation I'm in didn't arrise by accident. It evolved into what it is today by design. In other words, we had to make a conscious decision that business issues must be kept separate from the technical issues. If the business dictates (for example): "we need to put a system in place that will allow us to produce final statements in the most efficient manner", we (the technologists) take that requirement and run with it. But, we don't allow business people to breathe down our necks and to meddle in the technical decisions. We unilaterally decide which technology to use, how to design the product, and then let the business operations use it. Simple as that. And it works like a charm.

    >Yet, with all this being said, I marvel your ideal of
    >simple systems. I guess, Developers always strive to make
    >systems simple, because it is less work to develop. But,
    >darn it, it's the users who make the requirements, it's
    >the users who add the complexities, it's the users who
    >just don't wanna be standardized. Darn you, diversity, you
    >nature of human beings.

    Has it ever occurred to you that the users tend to make additional requirements, introduce further complexities, push for diversity and so forth, simply because there may be some sort of a fundamental flaw in the products they are trying to use? In other words, maybe the push for diversity is not the original cause stemming from the naughty users, maybe it's just a symptom, pointing to some deeper, more serious problem.

    Well, if some people are not imaginative enough to envision such a possibility, doesn't mean that such a possibility doesn't exist. If they're having difficulty envisioning a system that's much simpler than what they can imagine, and yet much more functional than what they can imagine, it's their problem, not the problem of the overall discipline of software development.

    A reasonable person will not waste time fighting the symptoms, but will make a concerted effort to get to the root of the problem. I advise you do the same when it comes to fighting complexity in the world of software development.

    >To summarize: Code generation - yes, but only for the
    >repetitive parts of development (e.g. use of
    >Middlegen/XDoclet to generate a data access layer). For
    >the business layer and presentation layer, a code
    >generator can help to build a skeleton, but most of the
    >work I believe must still be done by hand. I know, that
    >you are not agreeing, but I also know, that we are talkin
    >about different kind of systems.

    Code is totally irrelevant. Given a certain design, there are millions of ways to produce the implementation code (and there may be milions of different implementations of the same design). I don't really care about the implementation. What I care about is the *intentions*. Only intentions count in this situation. If your intentions are mislead, no amount of inspired hand coding will ever be able to bail you out.

    Alex
  65. User Intefaces[ Go to top ]

    For those who obsess about UI's, check this out.

    http://java.foundries.sourceforge.net/article.pl?sid=02/12/13/2336242
    http://www.nakedobjects.org/
  66. User Intefaces[ Go to top ]

    For those who obsess about UI's, check this out.


    The fact that Naked Objects have generated to much attention is an indicator of the sorry state today's software industry is in. Anyone who knows anything about how humans interact with software can plainly see that any system whose internals are allowed to 'bleed through' all the way to the end user is doomed to failure.

    Such attempts have been made before. Simply put, users absolutely don't care how was the system built, how was it put together. All that users care about is how can the system make their jobs/tasks easier.

    Let's examine the following quote that talks about the benefits of Naked Objects:

    "Because the user can see exactly how the system works, working with it is extremely straightforward."

    The user *doesn't* want to see *how* the system works. Same as the user doesn't want to see how a car works. The user only wants to use the car, and to be spared the gory details. Maybe the professional mechanic/engineer wants to see how the system works, but these users are in such an extreme minority, that we can safely ignore their wishes.

    Also, the 'empowering the users', rather than expecting them to be the 'process followers' mantra is a bunch of b.s. Users don't want to be empowered, they simply want to use products that will make their jobs/lives easier, or more bearable.

    Alex
  67. User Intefaces[ Go to top ]

    :)

    This is another one of those "go ahead and do it" things. I say implement away, go for it. If it works, great.

    Either way, the tasks of understanding the business and the tasks around those businesses doesn't go away. The UI is a small part of that. If we ever got to the point where a UI could be generated from that analysis, it'd be a good thing. Haven't seen that yet.

    And good lord, there's enough DEVELOPERS who can't understand objects and OO ideas. If we think we're going to be able to *easily* translate that to most users, we've got some issues. Most people think in a process-oriented, literal way, and exposing objects to them would be totally foreign to the way they process information. Ever tried to explain this to a non-OO developer? Try users.

    I am relatively confident that this will have problems, not because I don't support the technology or the idea. I know how people think and the hurdles they have to information processing, and this doesn't solve those fundamental cognitive issues. We're talking about people, not machines.
  68. User Intefaces[ Go to top ]

    This is another one of those "go ahead and do it" things.

    >I say implement away, go for it. If it works, great.

    Unlike yourself, I am less laid back when it comes to wasting inordinate amounts of time on any new fancy gimmick that may come along. Time is running out, the industry is in a major crisis, and frankly, we don't have the time to fool around with any half-baked idea that comes along.

    This one (i.e. Naked Object) is demonstrably a blind alley kind of an idea, so I don't see any merit in pursuing it all the way down to its bitter end. Some people may proclaim "I'm going down with the ship!", but I think that's foolish behavior.

    Alex
  69. User Intefaces[ Go to top ]

    "Time is running out, the industry is in a major crisis, and frankly, we don't have the time to fool around with any half-baked idea that comes along."

    I was going to attempt to argue with you on this, say you were being alarmist, but the truth is, I can't. You're right.

    I see it happening from my vantage point between business and IT. I see the lack of trust on both sides, the lack of partnering between development and the business. I see the hostility. Developers are mad at the business and the users, the business and the users keep saying developers don't deliver. The business' way of dealing with it is to attempt to scope a project themselves and buy a package to accomplish what they need, or to try to architect the whole thing themselves and hire someone who will just take orders and code exactly what they want, no questions, no arguments.

    That makes me very sad. I have nothing but respect for the craft of engineering excellent software. I see that losing respect, I see a lack of understanding from the business about the skill it takes to build really good software. But I see developers so frustrated that they don't want to even deal with the business and the users any more. But those people pay the bills and keep them employed, and it's become very easy for them to say "well, we'll buy a package, or we'll ship this overseas for development." We can say over and over what a bad idea that can be, but if their needs are met elsewhere, they will go there.

    This matters a lot to me, I work with serious software engineers and have so much respect for what they can accomplish and the value they add to a company. I don't like watching this happening, but there's not a lot I can do, except continue to try and talk it through on both sides, development and the business. But the gulf is there, and it's real, and because the business controls the purse-strings, the developers will ultimately lose. I've watched it happen over and over at the companies I work for. I'm pushing for an engineering team at the company I work for now, I can't get the business to understand why its important. It's not about the money. They don't trust in the ability to deliver what they need any more.

    So, you're right. The crisis is there.

    Elaine
  70. User Intefaces[ Go to top ]

    I see the hostility. Developers are mad at the business and the users, the business and the users keep saying developers don't deliver.


    I'm on users' side on this. Software Engineering is hoax in most cases. It's the way to rip off the customers.

    I'm sad for customers, not for engineers.
  71. User Intefaces[ Go to top ]

    And good lord, there's enough DEVELOPERS who can't understand objects and OO ideas.


    So, you are the one, who thinks that "everything's an object" :P
  72. User Intefaces[ Go to top ]

    LOL. No, I'm not. But I've seen what happens when people who do think everything is an object try to convince other people of that. You get the same reaction as the one you just gave me. :) So how can anyone say exposing the objects to the user community is going to make any more sense to them? If it annoys you, how do you think users will take it?

    That was my point.
  73. User Intefaces[ Go to top ]

    If it annoys you, how do you think users will take it?


    they bait it suprisingly well. OO people tell them "Database should be derived from the Object model", poor users take it seriously.
  74. Alex,

    I'd like to recommend to you some of what Martin Fowler has written about up-front design vs. evolutionary design (http://martinfowler.com/articles), and some of what Jakob Nielsen has written about usability and customization of user interfaces (http://useit.com/alertbox).
  75. So have you made millions selling it and replacing all the programmers in the world?
  76. So have you made millions selling it and replacing all the

    >programmers in the world?

    I would never do such a thing to the programmers.

    Alex
  77. Won't or can't? If you can do it, someone else can and they surely will sell it.
  78. So have you made millions selling it and replacing all the programmers in the world?


    It's already too late, they were all replaced by a system generator program called 'The Last One' - 'the last piece of software you'll ever need to buy' from around 1980 that took a plain English description of a system and generated the code! Sure Alex's is a vast improvement on that but I think I might be able to suggest a few scenarios where it wouldn't work.
  79. Sure Alex's is a vast improvement on that but I think I might be able to suggest a few scenarios where it wouldn't work.


    Actually, we all waste time. We should take Alex's program, exmplain it that we need a program which will write all other programs. So, we'll press the button, and it will write us all other programs, and we may go to vacation to Bahamas
  80. OK. I've recently developed an end-to-end framwerok that is centered around XML Schema documents. Users declare their business (including all the constraints and validations) in an XML Schema (i.e. a repository), and then my framework reads the XML Schema document(s) and generates the whole bloody application.


    1. I like it. I like declarative approach over imperative, when it's applicable. E.g., it's stupid to code data validation on every form. It's better to define forms declaratively (in XML?), then generate the code automatically. I never done complete/entire application generation this way. I'm afraid it would be practically impossible in the projects where I worked on, due to variety of reasons.

    2. More important comment: I believe you didn't code this end-to-end framework with other end-to-end framework :)
    I mean that you didn't define all your framework in XML, then pressed a button, then got "end-to-end framework" generated and ready for your users! I bet you coded it with C++/Java/Smalltalk/whatever. Maybe you used libraries or component framework etc. I believe that to develop such a product, you had to be one of the "highly paid coders", which you replaced. You can't be low paid user to do such things, especially if you have performance/scalability constraints.

    My point is that, there are repetetive/mundane/routine tasks, which must be automated. There are even domains where entire application generation can be achieved. Fortunately, much more tasks require creativity and intelligence in software development. Basically, anything "new" requires a human programmer. You can't INVENT "lexx" with a CASE tool. Frameworks and libraries can't replace programmers. They only help them to be higher paid than ever :)
  81. 2. More important comment: I believe you didn't code this

    >end-to-end framework with other end-to-end framework :)
    >I mean that you didn't define all your framework in XML,
    >then pressed a button, then got "end-to-end framework"
    >generated and ready for your users! I bet you coded it
    >with C++/Java/Smalltalk/whatever. Maybe you used libraries
    >or component framework etc. I believe that to develop such
    >a product, you had to be one of the "highly paid coders",
    >which you replaced. You can't be low paid user to do such
    >things, especially if you have performance/scalability
    >constraints.

    You are right. I had to manually code my framework. But you see, my framework is at a different level of abstraction than a regular business framework. My framework is a framework *about* other frameworks. It's a *meta* framework. And meta things live by different rules and standards than regular things (read Russell's and Whitehead's "Principia Mathematica" for an indepth study of that phenomenon).

    >My point is that, there are repetetive/mundane/routine
    >tasks, which must be automated. There are even domains
    >where entire application generation can be achieved.
    >Fortunately, much more tasks require creativity and
    >intelligence in software development. Basically,
    >anything "new" requires a human programmer. You can't
    >INVENT "lexx" with a CASE tool. Frameworks and libraries
    >can't replace programmers. They only help them to be
    >higher paid than ever :)

    Although I agree with you on this one, it is sort of a moot point. Meaning, you're talking about programming and I'm talking about designing. To me, anything "new" requires an intelligent designer (not a programmer). Once a designer solves the problem, the implementation code can be automatically generated.

    Alex
  82. Although I agree with you on this one, it is sort of a moot point. Meaning, you're talking about programming and I'm talking about designing. To me, anything "new" requires an intelligent designer (not a programmer). Once a designer solves the problem, the implementation code can be automatically generated.


    Alex,

    Let me remind my original point: the architect MUST code on everyday basis, he MUST be a very good programmer.

    If your system doesn't suck, then it would only support my point: you are a good programmer :) I don't believe in designers who don't code well. You consider yourself a designer. I hope you are a good one. Alright, I see that you hand coded your framework, meaning you are programming on every day basis. I believe your framework is complex and inordinary, that would only further convince me that ALL good architects are good programmers.

    cheers,
    Argyn
  83. I would like to understand the concept of the product manager - what problem is he talking about?

    In my experience, the biggest problem with Product Managers is that they rarely understand the customer or the prospects' real needs. They listen to sales and support - thus heeding the advice of our noisiest 10% of customers.

    Unfortunately, developers have not done much better. "Wouldn't it be cool" is a phrase that has cost companies billions in wasted features that no one wants. Microsoft's best feature improvement in 5 years has been to delete features that are rarely used. (cf Office 2000) MS Word and other office products were chocked full of obscure features only used by 10% of the user base. Most of us just need a typewriter!

    We need someone to listen to the market to help the craftsman figure out what to build. I'm all for developers becoming craftsman, but craftsman must fully understand the domain for witch they are crafting. To often developers' domain knowledge does not extend much beyond creating good code editors. VI and EMACS are great, but end-user software needs programmers who understand the end user. Or product managers who can help communicate thier needs.

    Paul
  84. Although the article has its merits, all this stuff seems like old news. I think we are trying to tackle problems with software development that have already been solved generically in the last 50 years. By having true leadership at all levels of the organization (which is a very effective and generic skill that all managers should possess), we can avoid all these software development problems altogether. An organic organization might be well suited for software development, but it's well suited for a lot of things. That is exactly where the problem lies.

    It's not that software development is any different - it's just that we complain how these issues more because of the types of people that make software want responsibility, want to innovate and want to be involved.

    In reality, there are good companies who are innovative and make good products, and there are bad companies where bureaucracy reigns and employees have little control of what happens - a paradigm where 'management' and 'control' are more of a concern.

    So if you ask me, all this is nothing new. We are just inventing the wheel all over again for companies that make software. However, this is much bigger problem with the organization's health itself and I think we should be exploring those issues first.

    Regards,
    Ken Egervari
  85. Interesting post. I find many of these things that he talked about are reminder points for all of us. Clearly, if we look at the changes in our working habits over the last ten years, we are moving in the direction that Alan Cooper talked about. His emphasis on software as a craft, and collaboration between professionals instead of turf warfare is a mindset that is at once a throwback to the days of craftsmen and guilds and also a reflection of how the internet today has allowed us to reduce the infrastructure with which we must surround ourselves in order to be productive and influence others.
    The more we remind ourselves of these things, the more likely they are to become a reality sooner than later.
    By the way -- the recession is over. The only reason the economy is weak is because people keep saying that the economy is weak. We need a little more resolve in this country. Let's get back to work! ;-)
  86. Interesting post. I find many of these things that he talked about are reminder points for all of us. Clearly, if we look at the changes in our working habits over the last ten years, we are moving in the direction that Alan Cooper talked about. His emphasis on software as a craft, and collaboration between professionals instead of turf warfare is a mindset that is at once a throwback to the days of craftsmen and guilds and also a reflection of how the internet today has allowed us to reduce the infrastructure with which we must surround ourselves in order to be productive and influence others.
    The more we remind ourselves of these things, the more likely they are to become a reality sooner than later.
    By the way -- the recession is over. The only reason the economy is weak is because people keep saying that the economy is weak. We need a little more resolve in this country. Let's get back to work! ;-)
  87. Interesting post. I find many of these things that he talked about are reminder points for all of us. Clearly, if we look at the changes in our working habits over the last ten years, we are moving in the direction that Alan Cooper talked about. His emphasis on software as a craft, and collaboration between professionals instead of turf warfare is a mindset that is at once a throwback to the days of craftsmen and guilds and also a reflection of how the internet today has allowed us to reduce the infrastructure with which we must surround ourselves in order to be productive and influence others.
    The more we remind ourselves of these things, the more likely they are to become a reality sooner than later.
    By the way -- the recession is over. The only reason the economy is weak is because people keep saying that the economy is weak. We need a little more resolve in this country. Let's get back to work! ;-)
  88. Interesting post. I find many of these things that he talked about are reminder points for all of us. Clearly, if we look at the changes in our working habits over the last ten years, we are moving in the direction that Alan Cooper talked about. His emphasis on software as a craft, and collaboration between professionals instead of turf warfare is a mindset that is at once a throwback to the days of craftsmen and guilds and also a reflection of how the internet today has allowed us to reduce the infrastructure with which we must surround ourselves in order to be productive and influence others.
    The more we remind ourselves of these things, the more likely they are to become a reality sooner than later.
    By the way -- the recession is over. The only reason the economy is weak is because people keep saying that the economy is weak. We need a little more resolve in this country. Let's get back to work! ;-)
  89. Interesting post. I find many of these things that he talked about are reminder points for all of us. Clearly, if we look at the changes in our working habits over the last ten years, we are moving in the direction that Alan Cooper talked about. His emphasis on software as a craft, and collaboration between professionals instead of turf warfare is a mindset that is at once a throwback to the days of craftsmen and guilds and also a reflection of how the internet today has allowed us to reduce the infrastructure with which we must surround ourselves in order to be productive and influence others.
    The more we remind ourselves of these things, the more likely they are to become a reality sooner than later.
    By the way -- the recession is over. The only reason the economy is weak is because people keep saying that the economy is weak. We need a little more resolve in this country. Let's get back to work! ;-)
  90. Interesting post. I find many of these things that he talked about are reminder points for all of us. Clearly, if we look at the changes in our working habits over the last ten years, we are moving in the direction that Alan Cooper talked about. His emphasis on software as a craft, and collaboration between professionals instead of turf warfare is a mindset that is at once a throwback to the days of craftsmen and guilds and also a reflection of how the internet today has allowed us to reduce the infrastructure with which we must surround ourselves in order to be productive and influence others.
    The more we remind ourselves of these things, the more likely they are to become a reality sooner than later.
    By the way -- the recession is over. The only reason the economy is weak is because people keep saying that the economy is weak. We need a little more resolve in this country. Let's get back to work! ;-)
  91. Interesting post. I find many of these things that he talked about are reminder points for all of us. Clearly, if we look at the changes in our working habits over the last ten years, we are moving in the direction that Alan Cooper talked about. His emphasis on software as a craft, and collaboration between professionals instead of turf warfare is a mindset that is at once a throwback to the days of craftsmen and guilds and also a reflection of how the internet today has allowed us to reduce the infrastructure with which we must surround ourselves in order to be productive and influence others.
    The more we remind ourselves of these things, the more likely they are to become a reality sooner than later.
    By the way -- the recession is over. The only reason the economy is weak is because people keep saying that the economy is weak. We need a little more resolve in this country. Let's get back to work! ;-)
  92. Interesting post. I find many of these things that he talked about are reminder points for all of us. Clearly, if we look at the changes in our working habits over the last ten years, we are moving in the direction that Alan Cooper talked about. His emphasis on software as a craft, and collaboration between professionals instead of turf warfare is a mindset that is at once a throwback to the days of craftsmen and guilds and also a reflection of how the internet today has allowed us to reduce the infrastructure with which we must surround ourselves in order to be productive and influence others.
    The more we remind ourselves of these things, the more likely they are to become a reality sooner than later.
    By the way -- the recession is over. The only reason the economy is weak is because people keep saying that the economy is weak. We need a little more resolve in this country. Let's get back to work! ;-)
  93. Interesting post. I find many of these things that he talked about are reminder points for all of us. Clearly, if we look at the changes in our working habits over the last ten years, we are moving in the direction that Alan Cooper talked about. His emphasis on software as a craft, and collaboration between professionals instead of turf warfare is a mindset that is at once a throwback to the days of craftsmen and guilds and also a reflection of how the internet today has allowed us to reduce the infrastructure with which we must surround ourselves in order to be productive and influence others.
    The more we remind ourselves of these things, the more likely they are to become a reality sooner than later.
    By the way -- the recession is over. The only reason the economy is weak is because people keep saying that the economy is weak. We need a little more resolve in this country. Let's get back to work! ;-)
  94. Nice To See that Mr. Cooper was not bashing programmers as usual. His first book was half decent but his second one(The Inmates are running the asylum) was a long rant.
  95. A Better Way... Let's form a Union[ Go to top ]

    how about a manifesto to unionize?
  96. Doesn't it all boil down to architecting/designing/programming being a science rather than an art ?

                    Yann

  97.  Doesn't it all boil down to architecting/designing/programming being a science rather than an art ?
    <
    Yes, it does--but it isn't. It is an art: which means that it INCLUDES a science, plus a great deal more. The great deal more is creativity, which is necessary to cope with the intrinsic complexity of software.

    This is the bone I would pick with Cooper: he adduces the old analogy between building software and building furniture, or bridges, or buildings, or cars. None of these things is ANYWHERE NEAR as complex as software; and the responsibility for designing the most complex physical things that we build--cars, airplanes, the space shuttle--is partitioned among many engineers, each of whom is responsible for only a small subsystem.

    The analogy with software breaks down on several levels.

    Software projects of (say) a million lines are not parcelled out to ten thousand developers each of whom writes a hundred lines, although this would be the analogy with the way airplanes are designed and built.

    Neither are airplanes built one-off from continually novel combinations of pre-built and custom-built components, although that would be the analogy with typical application development.

    And finally, the design of the 747 was not conceived, overseen or controlled at any level by any one individual super-architect, although that would be the analogy with the way many software projects are undertaken.

    If aircraft design were to be done on the super-architect model (as, decades ago, it was), that super-architect would have to be a creative person, because creativity is the only human aptitude that can usefully be brought to bear on complexity of that depth.

    So if Alan Cooper convinces you that software should be constructed rather than developed, be prepared to hire a really shocking number of non-creative people and set them to work constucting manageable pieces of the project. The results may be most excellent, although we are evading the question of how the many small pieces get defined and parcelled out....

    ...or hire a creative super-architect who can understand the complexity of the whole, and manage him in a productive way. This can be done; but it cannot be done be any of the techniques that managers are taught. Managers are taught to assign software projects to N people, and then manage them as if each one were dealing with so small a piece of the puzzle as would require 10N or 100N people to get the job done. No one should be surprised that this doesn't work.
  98. Good stuff but not new stuff, thirty odd years ago we were encouraged to think of development in the way Cooper suggests. The problem is that for ages most universities have provided courses that produce coders not developers, leaving the good people to get their development education as best they can and the bad people to produce bad systems. Many of the problems were similar, we didn't have RDBMS but we still had to get at data and I have long argued that RSX-11 was an early (the first?) OO operating system.

    In terms of analogies used in other posts, surely we wouldn't expect the architect to tell people how to lay bricks, (s)he would say what sort of bricks and where they should go. On that basis you should be cautious of a software architect who never codes but tells people how to code rather than what to code.
  99. <Q>
    In terms of analogies used in other posts, surely we wouldn't expect the architect to tell people how to lay bricks, (s)he would say what sort of bricks and where they should go. On that basis you should be cautious of a software architect who never codes but tells people how to code rather than what to code.
    </q>

    I would agree that an 'architect' needs to get their hands dirty. Especially with current technology and the environment that it operates. I don't know if they need to be coding everyday but it takes alot to stay current - developing and trying and learning new ways and things.

    I would say that most architects of a few years ago are out of touch with the present. Things have changed that much that quickly. Some will be able to change. Some won't.

    Reading a little about about what Cooper said, it seems the bigger problem is getting management to change. I think it might be next to impossible (barring exceptions). It is difficult enough to get 'developers' (etc.) to change let alone upper levels.