My next feat will be to rebut the first of two comments, “Software Practitioner Triad” Provokes Thought by Luke Ferris of Tucson.
Luke questions the separation of the “triad” Alan Cooper discusses in his article. First, I have to make a reference to a quote from Alan's article:
Today, web designers are called programmers, programmers are called engineers, engineers are called architects, and architects never get called.
This has been a time-honored truth for a while and I'm just glad to hear it said out loud. I don't want to get into a discussion on job titles just yet, but I think this quote shows how closely software engineering jobs are related. If we were construction workers, we wouldn't be able to cross these lines.
Programmers, engineers, and architects: the three pieces to Alan's puzzle. We all know what programmers do - they write code. Programmers don't point and click, they don't drag-n-drop, and they sure aren't “web masters.“ They code. They write software applications that solve complex business problems using custom coded components and modules. Programmers are the builders.
Engineers solve problems; they are the foundation builders. Can a programmer fill in for an engineer? Sure, but that doesn't mean that the programmer is an engineer. In most situations, programmers fill in for all 3 jobs. As Alan said, engineers are not intended to create code which should be immediately shipped. In my opinion, which differs from Alan's, engineers should create solutions to prove functional capabilities. While others may disagree, I think that an engineer should abide by all coding standards that programmers abide by. When an engineer proves some capability, the programmer(s) should take this solution and tie it into the specific problem at hand. For instance, if an engineer was to prove an n-tier application, s/he would create all of the needed components (minus the business logic) based on the requirements (I suggest using use-cases) and hand it over to programmers after appropriate testing. The programmers would then add the business logic required and detail out anything that was not necessary for the components to work for the prototype. These are sometimes refered to as architectural prototypes. APs are not throw-away. They should be fully used and extended to meet the specific needs of the application. In some cases, lead developers may decide to take these components and keep them abstract within a reusable component library of some sort.
Architects, the final and pivotal piece of the triad, draw the blueprints. Everyone knows that blueprints are the guidelines within which the rest of the workers must abide to. If any one person alters implementation of these plans, catastrophe may follow. Architects should have the knowledge and experience to map the requirements to a functional solution. Of course, there is never one solution and getting 25 people (or even a small team of 3) to agree on one is impossible. There are always pros and cons to each solution and any good architect should be able to come up with a few solutions and provide this list of pros and cons to customers, managers, engineers, and lead developers to allow everyone to provide input into the appropriate direction. Without this much-needed collaboration, any project could be doomed for failure in one form or another. Architects should have the power to direct the development effort as needed. They should provide the engineers with the architectural prototypes, which will eventually get to the developers to extend to meet the needs of the application.
Any combination of these jobs can technically be done by a single person. The problem is, if you combine efforts, you will be missing several key benefits of this ideal separation of power. If an architect is thinking about how easy or hard it will be to program, s/he may not chose the best architecture. Plus, different experiences and skill sets help us grow and challenge us to do better. Some small teams should not have these separated individuals, but that is a risk that small development teams must take. As I mentioned before, most projects don't use architects; especially when using Microsoft-based technologies. This is one key reason why applications based on Microsoft technologies (and even Microsoft's own apps) tend to lack the architecturally sound characteristics of some other technologies. It's not the platform, it's the practices...but, that's for another discussion.
Luke, you can mix-and-match as needed, but beware of the consequences. The best situation is to always have a collaborative effort with appropriate separation of power. Why do you think the US government does it? All the power in one [wo]man's hands can be very damaging.