Interaction Design Seminar
Interview with Alan Cooper: The Future of Software Development and the .NET Platform

Register Now!
Call (or )

So what do you really think about the .NET platform?
I was talking to Richard Hale Shaw at VSLive! Orlando last week, and he said that for the first time Microsoft let people who think about system architecture make the decisions. I agree with him. You’ve got to move toward portability and it isn’t about what you like Mr. Programmer.

How does .NET deliver more portability?
By providing cleavage points. It’s like cutting a diamond. You can’t just cut one; you search for the natural cleavage points in the diamond’s crystalline structure. Likewise you have to find the cleavage planes in the software and break it in two. Those cleavage planes of course are APIs and the CLR and MSIL interfaces are APIs.

I learned this years ago with VB 1. By creating the VBX interface it was clear from the beginning that we were creating opportunities for developers to build installable controls. It means there’s value to implementing something on the other side of the API. Borland could create Delphi and use those VBX controls.

If you do create value on one side you will create value on the other side. What Microsoft has done is by creating the interface with the CLR is they create opportunity for people to build their own runtimes. It's an opportunity for creating new languages.

That’s the power of APIs. It’s the component way of thinking on a larger scale.

And this helps corporate developers as well as ISVs by giving them more tool choices within a common framework.
Yes; however, software isn’t developed. For years I’ve talked about software development, but it’s a confusing label. Software doesn’t get developed. It gets built. It’s a construction project. Calling it development gives the impression that it’s an ongoing thing, and many of the ills we experience come from that. Buildings don’t get “developed.” They get built—they can be remodeled later. I’m trying to strike the word “development” from my technical vocabulary and talk about the software construction process.

Consider this observation: everything we build/construct in the real world comes from a long string of unselfconscious construction. Here’s a table. I’m sure there are people who’ve studied table making, table selling and so forth. But before that people made tables by taking a tree and laying it across a couple of stumps without thinking of it as a discipline. There are deep roots to this.

It’s true also for machines that come out of the industrial revolution—they replace manual things. So they’re extensions of things we did by hand, with roots in practicality.

The building of software is different. It doesn’t have roots in the physical world. And in fact software’s roots are in academia. Unfortunately for us, in academia success has a different definition. In the real world if the tree falls off the stumps it’s a failure; in academia it’s a successful experiment. In academia we think about developing an idea. Our roots are not in the pragmatic world of making mechanisms that serve us. Instead it’s in the scientific discipline of observing. That’s why we have so much trouble with the idea of building/constructing software.

If you look at the construction trades before the industrial rev there was craft. Craftsmen were highly skilled people who worked with their hands and heads to do difficult, complex work—they were masons, harness makers, cobblers, coopers. They had their tools/training/lore. And they built things that served a practical purpose.

The industrial revolution really changed that by creating the mechanic. The mechanic is also someone who’s building something. And underlying the work of the mechanic is the work of the engineer. The engineer is clearly another creation of the industrial age. The industrial age was the age of engines. But we’re not in the industrial age any more. That’s over.

Are you saying programmers are like mechanics or engineers or…?
I see that there’s a great deal of confusion about roles. Here are programmers who are very intelligent, highly skilled, doing a demanding job that is remarkably impenetrable to outsiders. Most people know more about how the Vatican works than about what programmers do. And I think that programmers’ education is still deeply rooted in the scientific discipline of approaching software construction as though it were a scientific experiment. When you’re constructing software you should have a pervasive awareness that as a craftsperson you’re exercising your craft to build something someone will use. Unfortuantely, this is not a constant in the software construction world. We resolve problems not in service of the user but in service of the engineer.

Reminds me of a saying I heard decades ago: “In course of every project it eventually becomes necessary to shoot the engineers—and begin production.”
In the world of software Web designers are called programmers. Programmers are called engineers. Engineers are called architects. And architects never get called anything. There's a real confusion about titles and roles. A lot comes from fact that before the industrial age craft was a peak achievement. If you were a political leader or owned property or were a priest, you had status in the community. But if you weren’t any of these, the only way to rise was as a craftsman. It was a big deal. Then the Industrial Age changed that and made craftsmen go away. We gave up craftsmanship to get availability. Engineers figure out how to make the machines that make the products. The engineer rose and the craftsman sank.

So software is engineering?
Having spent a long time in every role, I can tell you it’s a craft, as much as a stonemasons building a cathedral. Software programmers have more in common with masons than with engineers. Engineering –real engineering, not programming—is problem solving divorced from the needs of actual people.

What would you call those software architects who you say never get called?
AC: Here’s what I think the hierarchy should be: Architects synthesize people, purpose, and technology. If you just take people and technology you have art—entertainment. If you just take technology and purpose it’s engineering. And people and purpose without technology is psychology. Architects have to synthesize all this. People must get something practical achieved. A table is a mechanism to support eating. The architect creates a vision of a solution.

Doesn’t requirements analysis provide that?
Requirements analysis totally doesn’t solve the problem. [taking out some books] Here’s a book that I highly recommend: Software craftsmanship: The New Imperative, by Pete McBreen. The Extreme/Agile programming movement is very much in synch with Pete McBreen’s thinking. The programming world is boiling under the surface with two powerful movements emerging.

One is the engineering movement as exemplified by UML and the Rational Unified Process, describing how you plan/document huge projects. The other is the craft movement. McBreen’s asserts that programming is craft. This is echoed by people in the Extreme Programming [XP]/Agile Programming [AP] movement, which says it’s not about method but your individual skills. I love this. I think for the first time the world of software construction has a chance to get out of this academic cloud. The God programmers bow to is the one of their own construction, not one of serving a practical purpose. Programmers have gotten away with this for 50 years. Agile programming represents the first time programmers have faced up to the fact that their job is to make real software for real people to really use rather than just for our intellectual aggrandizement.

Sounds like you’re saying XP über RUP.
These two movements in the world of software—engineering and craft—appear to be moving in opposite directions. But I actually think they’re both right. The problem is that you can’t focus craft methods on engineering problems and vice versa, so the places where they break down is misapplying RUP to something that needs three craftsmen working on it or trying to use individual craft methods to do big projects.

Where is it carved in stone that we have to use the same method for all projects? A carpenter can build a house just fine, but you can’t carpent an aircraft carrier. OTOH if you’re used to building aircraft carriers, with giant metal shops building giant subassemblies, then you’ll try to build a small house using giant slabs assembled in a welding shop. This doesn’t mean what we know about building houses or aircraft carriers is wrong.

How do we wind up trying to drive nails with jackhammers (so to speak)?
One of the main reasons we don’t understand what we do is because there are two types of managers: software builders—and those who are scared of software builders. Software builders are hypercompetent, highly intelligent, and if the people who manage them have good management skills, they can’t interpret what the programmers do. And the managers who can understand don’t have good management skills. They’re focusing on developing their own understanding instead of serving the customers.

Great. We get to choose between lightweights or technoids with Asperger’s Syndrome.
As a result, programmers are not managed. Most of the business community is in denial about this. Inside the world of programming there’s a kind of tacit recognition that we’re not managed. Meanwhile software gets bigger and more complex, having moved from spaghetti code to structured software to OOP, which lets us build software bigger than programmers can hold inside their heads. So now you need multiple people working together, and in the same way that we’ve developed OOP we’ve got to develop a methodology for managing programming and programmers. And one discipline that’s emerging is RUP and the like.

You said both approaches are right in their own scale domain, didn’t you?
They’re both right as construction methodologies—not as management or planning tools. Yes, software is a craft. Yes, it’s engineering. But if you’re building, say, an FAA aircraft control system, you’ve got to have a lot of craftsmen building it and engineers engineering it, but neither discipline functions well as management tools. And a lot of business executives who are scared of all this are saying deep inside we don’t know how to manage them and then they hear about RUP and they say Yes! Then someone else comes to execs and says XP, and they say Yes! again.

And the answer is software architecture?
Here’s a book published through the Worldwide Institute of Software Architects [rummaging through a stack of books]: The Software Architect’s Profession, by Marc and Laura Sewell. I read this book and every single word of it spoke to me. Everything they say I agree with. It has a forward by Grady Booch, who says there’s a significant layer on top of programming which provides the bridge between business management and software construction (including both engineering and craft). It was so exciting to read this book. Kindred souls. Every word on each page in the first book glowed like it was written in fire, like Bob Dylan says.

So I bought the next book in the series, also under the mark of the WWISA. It’s called Software Architect Boot Camp. I opened this book and read that it provides the fundamental basics that every software architect needs to know. Now I see myself as a software architect, right in the middle of that triangle of people, purpose and technology. I understand people and I understand the pragmatic goals software is trying to reach. An application isn’t a monument—it’s a building that must serve some real purpose. Just like a building architect does.

On page two of this book it says the software architect both designs software and guides the construction of the software. It’s a collaborative process. Then I read that being a software architect is different from a manager because he’s a direct technical contributor.

So far so good, but by around page eight either the book or I go completely off the track. The authors start talking about all the different architecture approaches, but in fact they’re all engineering approaches. Nothing about users. Just use cases, which describe tasks from an engineering point of view. The book immediately leaps into detailed discussions of engineering. There’s nothing in this book that I do. I’m a software architect and I agree with the intro but I have no commonality with what they call the basics. It’s clearly engineering. Engineers don’t talk about why you want to build a building. They say how to do it efficiently. Use cases let you collect a spec like it has to be 40 stories tall—but nothing about why it needs to be 40 stories tall and what purposes it serves by being 40 stories tall.

On page 103 you finally get six paragraphs devoted to users’ needs, done very much at arm’s length. “The requirements should define the goals of the system….with the use cases defined we have established the cases for architectural planning.” What a terrible misstatement. That’s like saying with the statistic of the number of operations performed and the chosen wall colors we have established the design for building the hospital. It’s specious.

Sounds like a book on management by Asperger’s people who don’t know they’ve got Asperger’s.
“Architecture bridges the huge semantic gap between requirements and software,” the book says. But it clearly doesn’t, because it doesn’t pay any attention to the requirements. It goes straight from “We’ve performed 2,000 operations/year” to “And we want the hospital’s walls to be yellow.” It never asks “What are we building and how do we know it’s the right thing?”

The XP/Agile programmers see this gap and step into the fray. They ask “How do you know?” and say “Let’s build one operating room and see if it’s big enough and works.”

Which is wrong too, because it ignores how scaling issues can change a project qualitatively.
The engineering method the WWISA calls practical is not practical. The agile programming movement focuses on practicality but uses the wrong tools. And the top echelon of engineers has usurped the title Software Architect.
Yet the first WWISA book on theory was great, while yet the second was a big disconnect. I am not an engineer. I look at what engineers like Grady Booch do—I don’t understand it, and I’m not attracted to it, though I can see how it’s a useful tool when applied correctly. It’s got its role certainly. But not as a construction discipline and not as a management discipline.

Then I look at the XP/Agile programming people and I’m attracted to them for two reasons. They’re the first to be reaching out of programming to do something practical. As an entrepreneurial guy I’m strongly attracted to that. Then I look at what they do and I see that they do craft. They build beautiful things with their hands and their brains. I feel affinity with that. OTOH they say “We’ve seen planning and it doesn’t work so let’s throw it out.”

And you’re saying they haven’t seen planning.
Right. I tell them you haven’t seen planning and it does work, but you’re otherwise right on target. Real software architects do effective planning—they do research, work with stakeholders, distill what the real goals are. Then they begin to synthesize a real solution and hold the hands of the builders as they build. Organizations who have wholeheartedly adopted real planning methods such as ours have been able to create products that both users and programmers love. And they get enormous efficiencies, sometimes cutting development time as much as 50 percent.

Is iterative development part of your method?
“Programming is an iterative process,” the XP/Agile folks say. I say the act of delivering an appropriate solution to the user is iterative but if you do that in code it’s far more expensive than if you do that at the design stage, where it’s far cheaper, far more efficient. You should iterate, yes, but five times, not a thousand times. Virtue lies not in the iteration but in the successful course correction.

I’ve heard it asserted that in India programmers do much more planning than in America.
I don’t think programmers are very good at planning, nor planners very good at programming. Maybe it’s like choreographers and ballet dancers. The best choreographers have some dance experience, and the best architects have some practical experience. Architects who’ve spent a couple years swinging a hammer know the best. But they weren’t necessarily great programmers. I’ve done so much programming I have an innate sensitivity about what the programmers have to do. It’s interesting to me how programmers use their special programming abilities to solve programming problems. But what’s really strange about people who program is that it gives them this sense that they’ll solve all problems with those skills.

To a hammer all things look like a nail.
In the professions that are rooted in the physical world, Christopher Alexander (who invented patterns) describes what he calls the self-conscious process, with people reflecting on what they build, versus the unself-conconscious process. Programming is a self-conscious process. In the world of software we don’t have that enormous physical craftsman heritage. Engineers are really good at solving in vitro problems and programmers are really good at building stuff, so all these people realize there’s a crisis in software construction. Consequently all the engineers are trying to do plans and methodologies disassociated from reality, such as RUP, and the programmers are saying just let me build one room. I’m deeply respectful of the impetus both have to solve the problem, but they lack the sense of humility that the physical disciplines have.

The unique thing about software is that people in the software trade don’t see that their point of view is unique and only applicable in a unique situation. Every company has a controller, bookkeepers, financial analysts. If you went up to any one of them and said we want you to write code they’d say we can’t. But if you go to any programmer or engineer and say we want you to do financial software of some sort they’d jump right in.

That’s how you get accounting packages that can’t handle real world problems such as bounced checks.
I read on the Web where someone was trying to get a refund and the Web site would let him fill out a form for a price adjustment it had no provisions for a refund. He wound up using the price adjustment form, entering an amount that was a penny less than a full refund and it worked.

There are a bunch of problems here that are conflated. As an architect I believe there’s a grave wrong being done in that architects don’t have a role. Everyone’s breathing their own exhaust.

What do you think is the root cause?
AC: A lack of management. The RUP guys are using a valuable tool to solve the wrong problems; ditto XP/Agile tools. There’s a vacuum in software construction management. The architect—the true architect—asks some simple questions, such as: Before we start pouring concrete do we know what it is we’re building? The solution is to hire an architect and have him go out and figure it out. Then builders can build it using the best tools of their craft. This way you get much more efficient software devel—er, software construction.

Earlier you touched on requirements analysis. Isn’t that what you’re talking about here?
There’s a canard floating around that people know what they want. Another is that they want what they’re used to. But if a programmer does a new solution and the users scream, it’s because you’ve gone from a bad solution to another bad solution. There’s an enormous and growing body of scientific evidence that shows all this stuff to be true.

If you look at any construction project there are foremen and construction supervisors—a hierarchy of people whose job it is to keep the builders—the constructors—following the plans. The supervisors know the craft, the trade, and the blueprint, and it’s their job to make sure that the blueprint gets executed. They constantly have to corral the tradesmen. But in software construction nobody is playing the role of foreman or construction supervisor.

What about lead programmers?
The lead programmer is a construction person, and has different responsibilities. It’s like telling the carpenters to elect one of their own to run the group. But the lead programmer’s loyalty is to the programmers. There’s no self-interest there. No bonus if you build to the plan because there is no plan. There’s no management infrastructure inside software construction. Yet every other discipline has a robust infrastructure.

For example, noncoms in the military bridge the space between the officers and the enlisted men. All construction managers are NCOs but not all NCOs are construction managers (i.e. specialist warrant officers). I think there’s management at this level in every trade except programming. There’s this break in the command structure. Programmers are let loose. HR manages job benefits and IT management makes sure the programmers are working on the right project. But nobody’s comparing plan with execution daily. So there’s no sense that you need a plan. No call for it. Nobody in management has seen a plan so there’s no concept that you need somebody to guide programmers along the plan.

Consequently if you broach the idea of introducing a plan the programmers scream bloody murder. Ask Kent Beck what he thinks of plans and you’ll hear his voice two states away because he’s been victimized by engineering methodologies masquerading as architectural plans.

Sounds like you want to shake up the profession from one end to the other.
I want to make a point about the term “profession.” A profession isn’t something someone does for money. A profession is a state-sponsored monopoly granted in exchange for self-policing. You cannot practice dentistry in this country or state unless you’re a certified member of the ADA. The state supports that. If you pull my teeth without dental accreditation you’re committing a felony—practicing dentistry without a license.

However, it’s fine if you wire your house yourself, even if you’re not a licensed electrician. You can even wire my house. It’s not against the law, it’s not a state-sponsored monopoly, it’s a craft but not a profession.

The flip side of the coin for that state-sponsored monopoly is that the profession polices itself. The state expects the ADA to ensure that its members are appropriately trained and conscientious. They expect you to go through an institution accredited y the ADA, take the courses needed, get job experience as an intern, and finally get the license. Even then there’s a requirement for ongoing professional education. This is all done internally, and if you don’t follow the rules the ADA pulls your certification.

Do you really think we’ll see that sort of professionalization in IT?
It’s clear to me that the WWISA is gunning to become a profession, saying if you know all this stuff you can be a software architect. At some point they’ll go to the government and try for state sanction, then make people pass their tests—their bar exam—before you can practice software architecture.

Electricians aren’t professionals because they’re externally regulated. That’s why dentists get paid a lot more than electricians. One of the things that would have to happen for software builders /programmers/engineers to become professionals is they’d have to internally police themselves. But it’ll never happen because programmers by their very nature are libertarian, so the whole idea of submitting to that kind of internal regulation is antithetical to their way of thinking. Less so to engineers, and WWISA is clearly an organization of engineers.

If your call to arms isn’t for professionalization, what do you want to have happen?
There’s this upheaval going on inside the software industry. People outside the industry know it’s out of control. Software is expensive and gets obsoleted in a year. But people outside have no way of knowing that it doesn’t have to be that way. And people inside haven’t cared too much up to now. But there is some movement within the industry towards recognizing that it’s not all milk & honey. That’s providing the impetus behind these two movements. [UML/RUP and XP/Agile].

The engineer figures out how big the table boards need to be to not collapse under the weight of the soup in the bowl. Engineers don’t focus on purpose or people but on the tasks at hand and the materials at hand, in vitro.
Builders build it. They pay attention to what the engineers tell them and the vision the architects give them. The engineers say it needs to be 12” wide or it won’t hold up.

We started out discussing the .NET platform. Let’s get back to that. What do you think about the .NOT movement among VB6ers?
I’ve been buying books on C# and .NET for the past few weeks. .NET is without a doubt extremely complex and extremely difficult. Then again, what programmers do is extremely complex and extremely difficult. I agree with Grady Booch when he says programming is hard and intellectually demanding and always will be and always was. A lot of people got sucked into the programming world during the .COM boom. Now they’re discovering it’s not easy. I think that as we build bigger and more complex software systems we’re going to find that the tools are going to give us more power and reach but they’ll never make things easier.

It’s a version of Parkinson’s Law—expenditures always rise to meet the budget. Like the fact that until recently computers always cost $2K. They just do more now. And does .NET at least make it easier to do more complex tasks, even if the net complexity (so to speak) remains the same?
Without a doubt .NET is one of the great simplifying tools in the world of software. It goes a long way towards cleaning up a gigantic mess. Which is not such a great achievement when you realize it’s Microsoft that created this mess by building badly designed software year after year, layer upon layer, refusing to do any kind of thinking and planning, going at it straight from a programming point of view. And they knew. Back when I was an active Windows developer I worked hand in hand with their Windows development crew, which was just making randomly bad decisions, and they didn’t care. They weren’t responsible to anybody.

Many others and myself wound up doing design work unilaterally and just giving it to Microsoft. Even then sometimes they would come back to us and say Yeah that’s a good solution but we’re not going to build it. No rationale. Now .NET slices through a lot of that stuff.

Software construction has often resembled digging the Panama Canal with a teaspoon. You can make the walls of the canal perfectly straight. But this method of construction doesn’t really have a future, and the Panama Canals of the future will get ever larger.

Does this mean you believe Visual Studio 6 developers should move to VS.NET now?
We as software pros have to create tools to build software in a more cost-effective way. And we need better tools to do that. .NET is a better tool. Is it sufficiently better to compel you to invest the time and effort needed to move to it? I think the answer is yes—by a hair’s breadth. I think you have to move. And yes it’s going to be painful and expensive, and the advantage is going to be tangible but not overwhelming. So you have every right to squeal that you’ve been wronged, that they’re taking away your big roomy sedan and giving you a little compact that’s more efficient and doesn’t need to go into the shop so often and provides a collective advantage for society, but at the expense of some disadvantage for you personally.

Any other upsides besides a slight advantage over VS6 in using .NET?
Yes—breaking Microsoft’s monopoly. This is something else I like about .NET and the direction Microsoft is going with the things XML brings us. When you get bigger tools and get away from the teaspoon way of constructing software almost by definition the bigger tools have to be more self contained and independent than all the teaspoons are. We’re moving towards a componentized architecture with cleaner interfaces and advances such as self-describing data. This is sewing the seeds for breaking Microsoft’s monopoly, and for this reason alone we should move in .NET”s direction.

A Microsoft API such as the CLR allows an opening for other language vendors, as does offering Web services through XML. It means the days of getting all your services from one vendor—or even a single app—are numbered. Today Excel does everything spreadsheety, but this new architecture lets us glimpse a future where you can do a discounted rate of return using some Web service while still working within Excel. Right now an ISV can’t compete with Excel because the bar is so high. Whereas with a more open architecture you can replace just a tiny piece of it. For example, you could provide a better way to print spreadsheets and make your product the spreadsheet printer facility of choice. Users can pay money for the software or pay a penny every time users print a sheet. This holds a lot of promise for the economic model.

Do we need other languages?
It used to be that in order to write for Windows you needed C and the Windows API. That was tough for a COBOL programmer. And VB gave the industry the first tool that let you write Windows programs without a daunting language and an equally daunting API. C++ was powerful but still really difficult. People stayed with VB.

But VB has its roots in BASIC. You have to understand that BASIC is an acronym for Beginners All-purpoSe Instruction Code. It was a user-friendly Fortran for the educational environment. Fundamentally VB is a language with twisted roots that can never grow and be as powerful as you need it to be. C was more powerful but not OOP. And C++ has twisted roots too, though for the first time it provides a modern language based on C where backwards compatibility wasn’t a design target. The C# development team took what was good from C, C++, and VB. You can make a similar case with Java, by the way.

So the fundamental reason why you need to move from VB to C# is because it’s actually a well-thought-out language with an equally well-thought-out API in .NET, whereas the original Windows API showed no evidence of thought. Certainly C# and .NET are a significant step forward.

And .NET thorough OOP architecture helps, right?
I just think OOP is hard. A language like C# is hard because OOP is harder because it’s designed to solve bigger problems. Piloting a 500-passenger ferryboat around a harbor is a lot harder than maneuvering a one-person motorboat. This is true even if the ferryboat has just one person aboard. Sure the one-person motorboat or JetSki is easier to use. But it will only take one person. The ferry boat hard to use but you can add 499 people to it. OOP languages are designed to grow much farther. Of course VB.NET has OOP facilities in it, but they evolved instead of being designed in, and they’re filled with compromises. C# has very few compromises. C# is a computer scientist’s solution to a management problem since we don’t have good management. So we have RUP, XP, Agile, OOP, CLR—we need them all. But you’d need a lot less of each with good management.

Is the lack of good management a structural problem or a problem of not having enough brilliant people?
Is it about a few brilliant people or is there a methodology that can solve these problems? I learned that it’s not quite either of them. Having built big applications by myself I felt qualified. But could I give normal people the methodologies I’ve learned? The answer is yes. It doesn’t require genius to manage programmers and architect software. It does need a special aptitude, and that aptitude occurs with about the same frequency as programming aptitude. With the latter we know you have to be born to it and go through the training. They self-select, fortunately. But it turns out that the people who can do software architecture don’t have a path to a profession or a trade. So I can’t take somebody off the street and turn them into a software architect. But I can if they have the aptitude.

Are there any careers that provide better pickings?
They could be working in tech support or QA or even in product management or marketing. They need the tools just as the programmers need the language, but I’ve spent 10 years developing a set of methodologies that are powerful, are being widely adopted, and are effective. Because I’m a practitioner I come at it from the viewpoint of planning, not management. I wanted to know whether there’s a method of synthesizing a goal-directed methodology. And it works. It produces a powerful management tool—a set of blueprints for building software. I haven’t developed the associated management methods but I think they’re closely related and I think it doesn’t take a few rare geniuses. Software is special—you can’t pick software construction foreman from the general public. But it doesn’t requires someone with the brilliance and rarity of a Grady Booch either.

They’re out there. Latent. Did programmers exist before there were computers? No. They just did other things. My dad was an electrician. He had two hobbies. One was playing chess, where he was a perpetual intermediate. And he loved to make things with his hands. Had a workshop where he made things out of wood and metal. Furniture tools, things like that. He totally would have been a great programmer.

So just as there were no programmers when my dad was growing up today there are a lot of people who have the talent to be software architects and a whole other group of people who have the talent to be software construction supervisors. However, we have no academic institutions to identify the latter group. Programmers can self-select because they have a profession to self-select for.

If you interview 100 people in the software industry you’ll find these people. They’re out there. Most are not empowered. Most have no tools to use and aren’t effective whereas the programmers have enormous power and autonomy. I don’t think it’s a goal out of reach. But it’s going to demand that programmers adapt to kind of a New World Order.

You’ve got all sorts of good news for programmers, don’t you?
The transition from VB to. NET is going to seem tiny compared to the transition programmers are going to go through when they discover they can’t call their own shots. That’s going to be a big shock for a lot of people in the programming profession.

Traditionally the way that’s done is through the educational institutions, which are in this case the root of all the trouble. In academic institutions there’s this real abdication to programmers. Even the usability movement is based on coming in after the engineers determine what the software’s going to be and knocking off the rough edges. It’s the wrong priority.

See Alan in person. Check out the agenda now for the Cooper U/FTP Interaction Design Seminar.