"this is a well-known problem with code files that have desigable classes in them - the class that is to be designed has to be the first class in the file.  If you do the same thing in windows forms you get the following error: the class Form1 can be designed, but is not the first class in the file. Visual Studio requires that designers use the first class in the file. Move the class code so that it is the first class in the file and try loading the designer again."

It turns out I had changed a struct that was defined first in my file to a class. I moved that class to the end of the file and "mirabile dictu" everything worked.

So if this is a well known problem, why can't we get an error message just like in the Windows Forms case?

While it was clearly my mistake, Microsoft has a share of the blame here. Clearly this requirement makes it easier to build the workflow designer. It would have been just as easy to check if this class was not defined first, and issue an error message.

The Windows Workflow Foundation (WF) ships with a Policy Activity that allows you to execute a set of rules against your workflow. This activity contains a design time rules editor that allows you to create a set of rules. At run time, the Policy Activity runs these rules using the WF Rules engine.

Among other features, the rules engine allows you to prioritize rules and to set a chaining policy to govern rules evaluation.  The rules engine uses a set of Code DOM expressions to represent the rules. These rules can be run against any managed object, not just a workflow. Hence, the mechanisms of the rules engine have nothing to do with workflow. You can actually instantiate and use this rules engine without having to embed it inside of a workflow. You can use this rules engine to build rules-driven .NET applications.

I gave a talk at the last Las Vegas VSLive! that demonstrates how to do this. The first sample in the talk uses a workflow to demonstrate the power of the rules engine. The second and third samples use a very simple example to demonstrate how to use the engine outside of a workflow.

Two problems have to be solved.  You have to create a set of Code DOM expressions for the rules. You have to host the engine and supply it the rules and the object to run the rules against.

While the details are in the slides and the examples, here is the gist of the solution.

To use the rules engine at runtime, you pull the workflow rules out of some storage mechanism. The first sample uses a file. A WorkflowMarkupSerializer instance deserializes the stored rules to an instance of the RuleSet class.  A RuleValidation instance validates the rules against the type of the business object against which you will run the rules against. The Execute method on the RuleExecution class is used to invoke the rules engine and run the rules.

How do you create the rules? Ideally you would use some domain language, or domain based application, that would generate the rules as Code DOM expressions. If you were masochistic enough, you could create those expressions by hand.

As an alternative, the second sample hosts the Workflow rules editor dialog (RuleSetDialog class) to let you create the rules. Unfortunately, like the workflow designer, this is a programmer's tool, not a business analyst's tool. A WorkflowMarkupSerializer instance is used to serialize the rules to the appropriate storage.

I would be interested in hearing about how people use this engine to build rules driven applications.

"You are so young; you stand before beginnings. I would like to beg of you,

dear friend, as well as I can, to have patience with everything that remains unsolved in your heart. Try to love the questions themselves, like locked rooms and like books written in foreign languages. Do not now look for the answers. They cannot now be given to you because you could not live them. At present you need to live the question."

• Rainer Maria Rilke, Letters to a Young Poet

I learned programming in high school from a Fortran IV manual, which was like learning how to drive a car from the owner's manual—unexciting. Later, after taking an operating systems course at MIT, I gave up entirely on programming as a profession. I did not want to spend my life doing the same thing over and over again.

What made me change my mind and become a professional programmer? In large part it was Gerald M. Weinberg's The Psychology of Computer Programming, which I first read in 1982. Weinberg not only demonstrated that programming was more than technology, it is a social activity, but he showed how the social element related to the technical. In essence, he identified and addressed the types of fundamental questions that Rilke advised the young poet Franz Kappus to study. Such as:

• “What does it mean when we say a program is good?” I learned from Weinberg that a good program is as much a matter of cultural fit as technological merit. A designer has to understand that tradeoffs are made not only among technical factors, but among technical, social and economic constraints. Too often, I have seen engineers try to build the “perfect” product while ignoring ease of use or budget constraints.

• “How do you get programmers to work together as a team?” One programmer cannot do it all. Different people have different skills, different skills are needed at different parts of the project.

• “What is leadership all about?” How do you manage change and performance? Why do many managers manipulate programmers and tread them poorly and then wonder why they get poor results?
• “How do you find good programmers?” And just what does it mean to be a good programmer? Weinberg was one of the first to point out the stupidity of aptitude testing for programmers, and the importance of understanding individual psychology in dealing with programmers.

Weinberg confirmed my own intuition that software could have an enormous impact on society, and his discussion of programming as a social activity helped explain much of the “strange behavior” I saw around me as I began working on my first programs. For example, during one of my first projects, I saw that the inability of certain people to work together had more impact on the project’s outcome than the technological issues being debated.

Weinberg examined what a naïve programmer would consider just technical topics and demonstrated how the elements of human personality and interactions between people had just as much, if not more influence over the outcome of a computer programming project than the technical issues and debates.

By understanding the importance of questions such as these, even if not every question can be answered in every situation, my value as a programmer and designer transcends whatever today’s technology du jour happens to be. I would have to say that Weinberg’s book took years off my apprenticeship, and saved me much aggravation.

To this day, I view programming primarily as a human activity, with the technical merits secondary. This does not mean you can ignore the technical merits. What makes a programmer really great is not technical genius, but an understanding of the human context of what he or she is doing. Any programmer who creates a truly revolutionary and world-changing program understands this. Others did not, or did not care to, and their contributions are hidden behind or overwhelmed by others’ accomplishments.

It is incredible that a twenty-five year old programming text containing examples illustrated with technologies that many programmers today cannot even conceive of—I recently taught a programming class where not one of the students had any idea what a punched card or paper tape was—is still a great book.

I have signed the petition at: http://www.mwdadvisors.com/resources/stop-the-madness.php. SOA does not need another buzz word. I think SOA 2.0 ranks belong even ESB on the buzz word list.

This is also an experiment. We have heard of viral marketing. Let us see if we can have viral common sense.

How do workflow and service oriented architecture relate?

The real question is how service oriented architecture (SOA) and business processes relate.

Service orientation is about how to organize and utilize distributed capabilities that could be under the control of different owners.¹ Business Process Management (BPM) is about modeling, designing, deploying and managing business processes.²  Business processes are the capabilities, or the users of those capabilities. Workflow is a technology that builds the automated part of a business process. It integrates human decision with synchronous and asynchronous software systems. Of course this is somewhat recursive because a workflow could use other services in its implementation.

For me, SOA and BPM are not in conflict. People talk about layering BPM on top of SOA. Or that SOA is for IT folks, and BPM is for business people. In today's world, business cannot afford to have people who just think IT, or just think business. Given the way the human mind works, multiple models are often needed to think about certain problems.³ SOA and BPM are two different ways to think about the same problem: how organizations can best accomplish their missions. Thinking about business process will transform how you architect your services. Architecting your services will impact how you model your business processes.

¹ For more information about service oriented architecture take a look at the Reference Model that the OASIS TC that I am a member of has produced:  http://www.oasis-open.org/committees/download.php/18486/pr-2changes.pdf

² See http://ww6.infoworld.com/products/print_friendly.jsp?link=/article/06/02/20/75095_08FEbpmmap_1.html

³ See "Mental Models" by P.N. Johnson-Laird in Foundations of Cognitive Science edited by Michael I. Posner

I was interviewed by Carl Franklin and Richard Campbell on .NET Rocks: http://dotnetrocks.com/default.aspx?showID=183. Yes we talked about Workflow and SOA. But we touched on other topics such as the failure of technology to really make foreign language learning any better.

(Apologies to Christopher Alexander)

Christopher Alexander, the architect who inspired the Design Patterns movement, wrote a two part article that appeared in the April and May 1965 issues of Architectural Forum entitled “The City is Not a Tree.” The tree in the title is not a biological tree, but refers to a hierarchy being used as a way to organize how modern cities are built.

We all try to organize the world into neat categories. It helps us make sense of the world. Unfortunately, those categories and subcategories force us to view the world as a set of hierarchical categories. Alexander argued that architects who think that way produce buildings and cities that are sterile and unlivable. For example, zoning that refuses to mix residential, industrial and commercial use has some very severe drawbacks in transportation, living conditions, and tax policy.

The world has too many interrelationships to be viewed as a hierarchy, it is really a semi-lattice. Now there are parts of the world that are hierarchies. But a hierarchy is a semi-lattice, but the reverse is not true. The point is that if you view the world as a hierarchy you miss the true picture.

Software often has to model some part of the world. The World Wide Web is a semi-lattice. Image what the Web would be like if it could only be structured as a hierarchical directory such as Yahoo. Don’t get me wrong; neat categories are often useful. But Search has become such an important part of the Web because it allows you to capture the relationships in a semi-lattice.

Take the classic example I used to give my software engineering students when teaching them about abstraction and object-oriented systems: How do you define a chair? Of course they start out with a standard definition. A chair has a back, a seat, and four legs. But what about a bean bag? Or even a table? In the end, what emerges is that a chair is about a relationship between a piece of anatomy and surface that can support it.It is a relationship, not an object with constraints.

This is what led Alexander to focus on patterns and not components. Of course, some patterns could become components. But components (software or otherwise) are packaging artifacts, not fundamental abstractions. This is why the authors of Design Patterns have the principle of "Favor object composition over class inheritance." Class inheritance is a hierarchy. Object composition allows you to build a semi-lattice if that is appropriate.

Focusing on relationships means you focus on behavior, on what happens in the real world. Systems built on behavior are more flexible and more scalable than those based on constrained objects. Of course not all systems have to be flexible and scalable. Flexible and scalable often conflict with other desired goals such as performance.

Service orientation is based on focusing on the relationships or behaviors between the capabilities of distributed services because ultimately, a service performs some action in the real world. In service oriented systems you do not focus on constrained objects. You try to model the world as the semi-lattice it really is. 1

[1] Look at http://polaris.gseis.ucla.edu/pagre/simon.html for another interesting perspective.

One of the dogmas of messaging technology is that the "truth is always on the wire." In the context of interoperability that is certainly true. The message, not the platform object model that generated the message, is all that really exists between a service provider and consumer.

Like all principles it has its limits. The statement the "truth is on the wire" only means that using an agreed upon message format is equivalent to a using a common syntax for a language such as English. It does not matter how you define the message format. XML Schema, RelaxNG, or just "ask Alice" are all equivalent. Humans are better at handling ambiguity than machines, hence English syntax can be a lot looser than a message format. Nonetheless, the point remains valid.

Syntax tells you nothing about the semantics of the message. For those of you who abhor fancy terminology, semantics means nothing more or less than the real world actions that arise from processing the message.

Just like you can misunderstand an English sentence, you can "misunderstand" a SOAP message. This misunderstanding may be a programming error, or a misunderstood or mismatched policy.

For example, I send to my bank a correctly formatted message that says transfer $1000 from my cash reserve to my checking account. If the bank transfers the money from savings to checking, that is a programming error. The "wire truth" however was not violated.

Now suppose that the bank made the correct transfer, but the bank's policy (which I did not know of at the time) was to report such transfers to a credit bureau. My altered credit score resulted in a higher interest rate on the loan I was applying for. Understanding a service's policy is as important as understanding the message format.

Truth is not on the wire, truth is the real world effect of what happens when a SOAP message is processed. Truth is semantics.

Agile based software development methodologies often remind me of the story about the person who jumps off a 100 story building, and passing the 45th floor yells out "No problems yet!"

Agile based software methods have many good ideas. Their critique of the waterfall method has great merit. The best documentation is the code itself. Document based solutions do not work. But it does no good to demolish one myth only to have it be replaced by another.

To imagine that because the attempt to completely design everything up front is futile, the idea that you can iterate every few weeks and wind up with an adequate design is often wrong. That might work for a project that is strongly user interface or end-user driven. I doubt it would work for designing an air traffic control system, or system software such as Microsoft's Windows Communication Foundation. These kinds of projects have strong lifecycle requirements about safety, security, performance, or scalability. Often they require individuals to acquire new areas of knowledge or expertise.

Barry Boehm's spiral model of software development is a much better approach.¹ The idea behind the spiral model is that at each choice point in the software development process one assess the risk that the project could fail to meet its goals. Based on that analysis the next step is to mitigate that risk. It might mean doing a prototype, refining the requirements, or doing more testing. Some of these tasks may be done concurrently. Analyzing the results of these steps might cause the development process to backtrack. In all cases, the views of all the project stakeholders (customers, developers, marketing, etc.) are considered at each analysis point.

Given this approach, the classic view (from Boehm's original paper) looks like a spiral:



Since the spiral model is a risk driven process, some circumstances might dictate an agile methodology. Other cases would require other approaches. By making risk the focus, rather than a manifesto of principles there is a higher probability of making the correct choices.

Let risk mitigation guide your development process.

1. Boehm's original paper appeared in IEEE Computer 21(5) 61-72 in 1988. In 2000 he updated the model at the "Spiral Development: Experience, Principles, and Refinements Spiral Development Workshop".

One of the benefits of service oriented systems is that they are loosely coupled.

David Orchard analyzes what loose coupling means from the perspective of the Web services stack. A human being can recognize that a field in a form is misplaced, software cannot. So for a particular message invocation, early binding is necessary. This is certainly true for standards. There needs to be a defined place for addresses and security tokens.

Orchard asks us to imagine Purchase Order system. A particular piece of information in a particular message must be bound to the appropriate programming types. If you need to know the name of the purchaser, you must early bind to the format of that name. Or to use fancy language, the service must understand its semantics. But it is only necessary for those programming types that the service needs to understand. Here is where building service interactions as messages rather than as remote procedure calls (RPC) is important.

If a service interaction is defined in terms of RPC, then if you change the semantics, you must change the service interface. As long as one type of the method call changes, the whole interface is broken. If you send messages (concretely XML messages), so long as the service can find the information it needs, the service is not bound to a particular message format. Other information can change, but the service does not care.

For example, if a service processing a message does not care about security, they can ignore the WS-Security SOAP headers. Those headers can change and the service can ignore all the security possibilities. The inventory service does not care if the credit information changes.

True, if XPath is used you are dependent on a certain structure to find information, but if you mark your documents with its version, or associated XML Schema, you could use the appropriate location path for the document. Or if you want to bind everything to type you can use the appropriate XML Schema instance to serialize the message to the appropriate programming types.

Loose coupling at the application level is about inserting levels of indirection to handle versioning (so what else is new?). But a message can do this because at the service interface the message is opaque. A RPC is not opaque.

At the application level loose coupling is how easy is to make a change that does not impact other parts of the system. With opaque messaging, a new version can be added without impacting other clients. If a service wants to reject a version it no longer supports, or does not yet support, it can do so without impacting other clients. In this restricted, but vitally important sense, semantic meaning in a Web service can be late bound.

Sarbanes-Oxley mandates that public companies should be able to produce all materially relevant transactions during an audit.

In the world of service oriented architecture, huge volumes of business documents flow freely as messages between services. These services are orchestrated (or choreographed if you wish) to produced business processes. To give you some idea of the volume, some people fear that the volume of XML is starting to take larger and larger fractions of network bandwidth. This is why some are starting to push the use of Binary XML for SOA messages.

In this world of huge stores of electronic messages and documents, how in the world do you find all the relevant ones? This is where XML Schema comes to the rescue. Your XML documents should be defined with schema, and hence subject to validation. Performance considerations may dictate that you do not validate your documents during message processing. Nonetheless, with schema definitions you should be able to query your messages to search and find the relevant documents.

For example, if you need to find all transactions with a given company worth over a certain threshold, you have to the tools to find it.

Grady Booch has fired another attacking missile in the great debate over software factories, and the idea's defenders have replied. Microsoft's view of the world is outlined in a series of articles by Jack Greenfield on the MSDN site:
http://msdn.microsoft.com/architecture/overview/softwarefactories/default.aspx?pull=/library/en-us/dnmaj/html/aj3softfac.asp http://msdn.microsoft.com/architecture/overview/softwarefactories/default.aspx?pull=/library/en-us/dnbda/html/softwarefactwo.asp http://msdn.microsoft.com/architecture/overview/softwarefactories/default.aspx?pull=/library/en-us/dnbda/html/softfact3.asp

The basic idea behind software factories is to move the production of software from a craft to an industry resembling manufacturing. This is not a new idea. In the second article, after reviewing why these efforts have failed in the past, Greenfield says:

"We are unable to achieve commercially significant levels of reuse beyond platform technology. The primary cause of this problem is that we develop most software products as individuals in isolation from other software products. We treat every software product as unique, although most are more similar to others than they are different from them. Return on investment in software development would be far higher if multiple versions or multiple products were taken into account during software product planning. Consequently, we rarely make commercially significant investments in identifying, harvesting, packaging and distributing reusable assets. The reuse that does occur is ad hoc, rather than systematic. Given the low probably that a component can be reused in a context other than the one for which it was designed, ad hoc reuse is almost an oxymoron. Reuse rarely occurs unless it is explicitly planned in advance."

I agree as far as he goes, but I do not think he fully comes to grips with why the idea of software factories has a long way to go. No doubt part of the reason is that the idea of a software factory resembles the idea of artificial intelligence. Every success redefines the goal. Nonetheless, I think there is a more fundamental reason.

Programming has always been a labor intensive activity. As a result, from the very start people have tried to figure out how to automate as much of the process as possible. Compilers were one of the very first attempts to automate software development. Today we take them for granted, but well into the 1970s people were still arguing over whether a good human assembly language programmer could code better than a compiler. Debuggers, linkers, loaders, file systems, operating systems, distributed transaction coordinators, were all invented to automate parts of the software development. How long did it take for the idea of a virtual machine (as in Java or .NET) to become practical for most software development?

You can, as Greenfield does, view these artifacts as improved abstractions. Abstractions are very critical to software development. I view these developments differently. I see them as automating what we understand how to automate. Code libraries such as for .NET and Java are in the same category. After years of experience we now understand enough of some of the critical elements of certain parts of software development to encapsulate them in libraries.

But software is not like other engineering pursuits such as bridge building. Most bridges, although they look different, are really one a few basic kinds. Because you cannot copy a bridge like you can copy a program, you need to build a new bridge at every place you need to cross a river. Hence you can much more easily replicate what you did before, or learn from experience.

This really came became clear to me when I was a graduate student in nuclear engineering. In the reactor design course final exam we were asked to design a cooling system for a nuclear reactor. We were not, however, to use our fundamental understanding of physics and engineering to do this. We were to apply the American Society of Mechanical Engineering (AMSE) standards for cooling systems to do the design.

Why has this been so difficult to do with software? Since software is easy to copy, you only need to create a new piece of software when you need to do something new. Automation is about understanding what you have done in the past. You cannot automate what you do not understand. So much of software development is done for things we have not done before. We do not know, or do not fully understand the domain models that Greenfield relies on for the idea of software factories. This is why the CASE tools, or the code generators of the past have not provided any reduction in cost and time. This is why I think UML based code generators will not be wildly successful either.

Of course you need to understand the domain models. It is just that in a dynamic economic environment, you do not arrive at the knowledge in time to automate the process until it becomes yesterday's understanding. As yesterday's understanding it will take a while to see if it is fundamental enough to be worth automating.

So long as software is about innovation, or doing what we do not yet understand how to do, it will always have a large craft component. Maybe automation will decrease the need for programmers, and thus reduce the labor cost. So far this has not happened in 60 years. People may use cheaper programmers, but that is another story for another time.

David Chappell, in his latest newsletter , argues that Service Oriented Architecture (SOA) promotes software reuse far better than objects do. For him, object reuse usually fails for two reasons. First, in an evolving business environment it is difficult to come up with a good definition of a business object such as a customer. Second, software developers seem to catch the not-invented-here plague fairly easily.

I certainly agree with this.

One of my favorite questions when discussing object oriented design with students is to ask for the definition of a chair. Invariably, the answers will include legs. Then I ask them if an ottoman or a bean bag chair fits their definition. Coming up with good class definitions is hard. I have been involved in software development long enough to have frequently seen the not-invented-here syndrome.

He also argues that the best examples of reuse occur with applications such as PeopleSoft or SAP. SOA reuse resembles application reuse. I certainly agree with this as well.

But, in my opinion, the fundamental reason that reuse with SOA will be more frequent than with objects is that SOA reuse is loosely-coupled black box reuse, most object reuse is tightly-coupled white box reuse. SOA is a design pattern that has benefited from our struggles with object-oriented approaches.

When you treat a component as a black box you interact with it through its external properties, or as we say in the programming world, its interfaces. You do not have to understand how a fork is built or what it is composed of. If you do not like your two-pronged desert fork, you get a three-pronged fork to eat your peas. You do not try to modify the two-pronged fork. The real world is loosely coupled.

With inheritance you must understand the object's implementation. You must always be aware of the fragile base class problem. You can change the behavior of existing programs if you are not careful. This only reinforces the not-invented-here syndrome because it is perceived to be easier to write classes from scratch, than to try to understand another programmer's code. Objects are tightly coupled because they are connected through a stack and a linker/loader.

Modern object oriented practitioners have realized this. The design patterns community emphasizes composition/delegation over inheritance, and interfaces over implementation. You use the component through its interface treating it as a black box. Interfaces produce looser coupling.

SOA is a design pattern for building business process in the real world. It does not tell you how to architect your application. It does not provide an implementation. It does tell you to construct your services completely independent of each other. Services are independently deployed. Code or database tables are not shared between services. Services in a SOA interact through a loosely coupled interface that is defined as a series of messages.

SOA is a continuation in the large of what good object oriented designs have started to become: less emphasis on the classes, and more emphasis on the loose coupling provided by interfaces. Obviously objects provide the actual implementation, but that is not how the users of those implementations view them. They view them as black box interfaces.

Class frameworks such as J2EE and .NET have been successful. Both those frameworks, encapsulate stable, well-understood problems that the software world has been working on for over 50 years. Not only are the problems of business not well understood, the environment is quite dynamic. Services in a SOA are loosely coupled black boxes because they reflect the loosely coupled real world.

Everybody talks about how the New England Patriots Super Bowl win last year was a team effort. Whether it was the backup quarterback imitating Peyton Manning on the scout team, the statisticians, the players, the coach, or the personnel guy, everybody contributed.

Teamwork, of course, is one the perennial topics du jour in the software world. Demarco and Lister’s classic Peopleware talks about it, introducing the concept of a “jelled” team. All the variants of Extreme Programming rave about it.

But what makes a team good? It is difficult to have a good discussion about software teams because there are not enough public concrete case studies. Could sports teams provide a basis for such a discussion?

Peter Drucker, the management expert, thought so. In a Wall Street Journal essay written several years ago, he discussed three paradigmatic teams: baseball, football and tennis.

What type of team does your organization have? As Drucker makes clear in his essay these teams are distinct alternatives. They have unique strengths and weaknesses, but attempts to combine parts of each are a recipe for disaster.

I bet a lot of traditional software organizations have baseball style teams. You do not play as baseball team, you are a member of the team. The third baseman never pitches, the tester does not do development. Designers do not have much interaction with developers. This is the old-style Detroit assembly line. The big advantage to this team is that it makes it easy to train and evaluate personnel. Everybody can be a "star" no matter how difficult they are to get along with. On many plays, certain players are not important. The left fielder does not do much on a routine ground ball to the second baseman. Symphony orchestras are like this as well.

This approach works well when the task is well understood and can be reduced to "routine". Here one can understand the drive to outsource and offshore software tasks. If things are well defined, and competence exists elsewhere, then price drives all.

The problem comes when you need to innovate quickly.

Football teams are more flexible. There is no equivalent to the halfback option pass in baseball. On almost every play, every player is necessary, if for no other reason then to prevent some other player from getting to the ball carrier, or the quarterback. Everybody works in parallel. Unlike baseball, everybody has to follow the coach's orders or else the team will not win. You have to train together to be effective.

How do you evaluate and train people? An individual's value is often related to how they complement the rest of the team, not only on their individual strengths and weaknesses. Play without a linebacker or a safety, and you will fail just as if you played without a quarterback. But why do quarterbacks get more money? Why do they both get more money than teachers? This is the old diamond-water paradox in economics ( http://www.libertyhaven.com/noneoftheabove/sports/praiseathletes.shtml or http://www.ace.uiuc.edu/Classes/ace100/lectures/Lecture_1.pdf ). Here you have to reward people based on their marginal value to your team, not on some absolute scale. It is much harder to outsource, much less offshore if you live in this world.

You still need, as Drucker points out, a score to evaluate how well the team is doing. Though as any football fan will tell you, the score does not relate well to how an individual player is doing. That is why you have to "watch film" to evaluate players, something baseball sabermetricians ( http://www-math.bgsu.edu/~albert/papers/saber.html ) do not have to do. Software managers in this world really have to understand what is going on in order to evaluate and train their people.

Finally there are tennis doubles teams (or jazz combos). There are no clear players, only roles to be filled by different team members at different times. This is the ultimate in flexibility and adoptability to changing circumstances. But there really has to be a fit here. How do you train and compensate in such a world where you can succeed or fail, but there is no score. It is hard to relate the end result to the individual. You certainly cannot outsource or offshore here.

As Drucker says, teams are tools, and you have to understand your environment and pick the appropriate approach. This is what management is all about.

One of the recently discovered Internet Explorer bugs allows malicious sites to install key stroke recording code on your system. This certainly has got a lot of press and deservedly so because of the widespread presence of IE as a browser.

Every time this happens I wonder, does open source produce more secure code? Do “more eyeballs” reviewing the code produce better code? Looking over the list of vulnerabilities on the US-Cert Issues Advisory list makes me doubt that this is true.

Based on my experience, too many reviewers often make for poorer reviews. Remember the last time you had to sign off on a document with a long list of reviewers? The early reviewers glance at the document knowing more reviewers will look at it later. The later reviewers assume the early reviewers did most of the work already. The result is a lackadaisical, poor job of reviewing. You cannot tell me that the open source community is immune from the natural tendencies of human nature.

Approval by committee is no different than design by committee. Just because the committee is larger does not automatically make the review better.

Driving on the highway around Boston I was wondering about its virtual counterpart, the Information Superhighway. Massachusetts’s accident rate is the highest in the country. People mutter in frustration, “You can’t get there from here” as they navigate streets that look as if cow meanderings determined their path. Yet people and commerce move with an ease and openness that can only imagined on the Information Superhighway.

What makes one so open and the other not? Some might proclaim “Heed the Three Opens of Modern Enterprise Architecture: Open Source, Open Standards, and Open Data.” In my mind I compared the concrete and virtual parallels.

The most obvious analogy is Open Standards. Traffic laws allow for vehicles to travel. Vehicles must be able to signal turns. Vehicles have to stay in lane. They have stop lights and backup lights. In fact any vehicle that follows these standards is allowed on the road. Much to the chagrin of many drivers, following these standards allows bicycles on the road. Standards can even allow for varying defaults. Everywhere but New York City has “right turn on red” as the default. When vehicles arrive at their destination then the work begins.

Vehicles are similar to messages. Open standards define the contents of a message and allow them to get to their proper destination. When the messages arrive at their destination, the actual work begins. Here Web Services standards (SOAP, WSDL, WS-Security, etc.) seem to have reached critical mass. While much more work needs to be done, the industry seems to understand what must be done (routing, federated security, etc.), although in some areas, such as transactions, it is not clear what the right approach is.

Applications create these messages. Viewed in this light, the dispute over Open Source does not seem as important as Open Standards. How the vehicles are built is not as important as their ability to interoperate on the open road. Yes, both the real and virtual counterparts have to be reliable and economic. You have to be able to upgrade and maintain them. But how that is accomplished is not critical to either superhighway. Some drive a BMW, others a Ford Escort. Different cars perform differently, they just have to perform. The success of the Information Superhighway does not depend on the success or failure of Open Source.

What does matter is what happens when the message or vehicle arrives at its destination. This is where commerce, recreation, or whatever occurs. In the real world, human beings can interpret the ambiguity of their interaction. To sign into a building, a security guard can judge whether the picture on your driver’s license (your federated security id) matches the person in front of them. A human can interpret the way you write out your address, or whether you put dashes or dots in your phone number. Data need not be strongly typed in the real world.

The data that moves on the Information Superhighway is different. If two applications have a different way of encoding an address, or a list of drug interactions in a data structure, these applications cannot interoperate even if they can exchange messages. Without Open Data information cannot easily move.

There is much sound and fury over Open Source, much love and singing kumbaya with Open Standards, and confusion over Open Data. Open Source and Open Standards people understand. But what is this “Open Data” concept? Look at one of the great intellectual popularity contests of our generation, Google (6/4/2004) by searching on the terms “open source”, “open standards” and “open data” and see the quality of what comes back, the first two are understood terms, the latter is not.

XML by itself does not help here. A customer record, or an address, or a list of drug interactions can be encoded in any one of several posssible sets of XML elements. Open Data requires XML Schema so that XML can be typed. If organizations can agree on the appropriate schemas they will be able to transform the content of their messages into their applications data structures.

Open Data is the missing link to make the Information Superhighway a reality. How can you integrate business services unless you have Open Data? You can talk about Service Oriented Architecture (SOA) until you are blue in the face, but without Open Data it will all be pointless. SOA is a way to build flexible, evolvable applications, but it is the moving of data that makes the building of services a useful endeavor.

It will take a while before enterprises learn how to achieve Open Data. On the other hand, do not be overly discouraged. Our automotive superhighway was like that once. Imagine what driving across the country in the late 19th or early 20th century was like. There were only 150 miles of paved road in the US in 1903. It was an adventure. Read books such as “Horatio’s Drive: America’s First Road Trip” by Dayton Duncan and Ken Burns, or “Coast to Coast by Automobile” by Curt McConnell and compare those experiences with ours today. We tend to forget how far we came, and how long it took us.

Over lunch the other day, a programmer mentioned that Gamma, et.al’s book Design Patterns revolutionized his thinking about software development. He asked me what programming books revolutionized my thinking. I agreed that Design Patterns changed the way I think about software, but I did not consider it revolutionary.

Thinking about this later, I realized that the most important books that I had read were not about the mechanics of programming itself, or about designing, or architecting software. They were about the cultural anthropology of programmers.

Cultural anthropology studies the patterns of human relationships in areas such as language, communication, socialization, relationships, and politics. Cultural anthropologists try to relate the organization of a person’s mind to their behavior. Books that helped me understand the programmer’s mind, and how it relates to their behavior have revolutionized the way I think about software development.

The success or failure of programming projects that I have been part of usually has less to do with the technology, than of the patterns of human relationships. One of my favorite examples is the software project whose architecture followed the corporate structure – the application groups designed the applications, the graphics group the graphics, the database group the database, and the user interface group the user interface. The resulting program was like feudal Europe; it did not work well together.

Here, in no particular order, are the books that have really influenced me.

The Mythical Man-Month by Frederick P. Brooks - pure wisdom about why software projects succeed or fail. See my review of it here .

The Psychology of Computer Programming by Gerald M. Weinberg - the first book that got me to see programming as a human activity, and why understanding human behavior is important to understanding how to build better software.

Both these books have been republished with new material. Get the latest editions.

Peopleware by Tom Demarco and Timothy Lister - a great book on the workplace and software teams. This is a book your supervisor should read as well. There is a second edition of the book, but I have not read it.

Donald E. Knuth wrote two essays that strongly influenced me. While dated, and I do not recommend them as strongly as the others, I feel obliged to mention them. The first, "Structured Programming with goto statements", written in 1974, made me realize the importance of thinking about software structure, and not language constructs. The point of the article is not that gotos are great things; but that the correct level of abstraction is critical to writing good programs. The second, “Literate Programming”, written in 1984, got me to realize that software programs could be written clearly using literary concepts. Programs that are clear to human readers are better programs because they are clear about what they want to accomplish. Both essays have been reprinted in the book Literate Programming.