|
I left university not too long ago and have worked in industry since then. I'm slowly recovering from the transition phase now. Psychologists suggest that you don't bury things inside yourself but that you talk or write about it. So that's what I'm going to do now.
Joining the industrial workforce, I got the chance to participate in projects, review and hear from other projects, and, most importantly, I got the chance to talk with more experienced people and learn from them. I had to make sense of what I saw based on my university education, and by and large I succeeded. But not as I had thought I would.
Essentially, I learned about architectural styles, but not those you would call "pipes and filters", "implicit invocation" or "object-orientation" but styles of a rather different kind. A human kind of styles. In the remainder of this short article I will list some of these styles and discuss how I think that they positively or negatively affect software development projects.
The first architectural style I knew even before I entered university. It might be called the "Spaghetti Code" architectural style of software system design. In this style, you will find any number of components and any number of connectors. System composition works according to a single maxime: anything goes, but nothing works.
Partially in reaction to the shortcomings of the spaghetti code style, projects sometimes seem to apply the "Bureaucracy" architectural style (also known as the Peter Principle style). Here, the system architecture is based on a functional decomposition of the system, such that there is exactly one component for each developer. The only composition constraint is that the component hierarchy must truly reflect the hierarchy of the development team. Changes in the development team will immediately be reflected in the software architecture. Exactly those connectors are provided which serve to maintain the hierarchy.
Then there is the "Let's Go Meta" style of software architecture. It is based on a single component, Object, and a single connector, from Object to Object. Everything else is just a trivial consequence. The rationale behind this style is that we as software engineers seem to prefer to deal with the computer science domain (the meta-level) rather than any application domain. Compared with computer science abstractions, any real-world application domain seems shallow. I first understood this style when I heard myself saying "I can do this with fewer lines of code."
Now, these three exemplary styles usually have a negative affect on software architectures. Fortunately, I also learned about styles which have a positive affect on project success. The first one leaves me with mixed feelings, though: It is a successful style, but it doesn't feel like it should be.
The "Worse is Better" architectural style is usually used by pragmatically challenged developers. "Worse is Better" means that you are willing to give up interface simplicity in return for ease of implementation [1]. In this style, you will typically find any number of components, but less than you would expect, and any number of connectors, but more than you would hope for. The only composition constraint is the deadline. I learned about this style when I once found a class called ListWith5Items which inherited five times from Item.
One day, I met a very experienced project leader, and she told me about the "Lone Island" architectural style. She said: "If an involved team doesn't work according to the project's overall goals, and you don't have a handle for making it work productively with acceptable cost, consider using the Lone Island architectural style. This style has any number of components, but no connectors. Make sure that the team in question gets to do those components." In this style, there are no relevant composition constraints, mainly because you don't care what happens on that island.
In truly large systems, the common point is often missed. As can be heard from reliable sources, the situation frequently resembles that of 16-18th century Germany: Many small kingdoms and lots of custom duties to pay at the border. Thus, I finally learned about the "Straight Jacket" architectural style. If you discover the control flow of your frameworks in strange places where you would never expect it, this might be the right style to apply. It seems to suit CS 101 challenged programmers best. The style defines one component for each challenged developer, and one connector from this component to the rest of the system. The governing laws within this component are likely to be Assembler or COBOL (C, C++, Smalltalk and you name it sometimes do as well).
So much about some of the styles I've seen. I'm sure you've seen them too, and most likely know many more.
I wonder how this article would have looked like had I written it up as a regular journal submission. I guess, an abstract of such a paper might read like this:
Software development can be interpreted as the application of architectural styles to software systems. However, software systems can also be understood as the application of humans to software development. Putting humans first then, it is best to apply the right developers in order to build adequate software systems. This application isn't easy though, and should match appropriate architectural styles. This paper discusses the relationship between software developers and architectural styles and shows that these styles should adapt to human abilities, fallabilities and needs. Project success critically depends on achieving this goal. The paper thereby concludes that architectural styles are by their very nature a human endeavor.
Dirk Riehle, Zurich, Switzerland.
Footnotes
Presented at David Notkin's "Novel notions, wild ideas and fun flames" session at SIGSOFT '96, San Francisco, CA, USA.
References
[1] Richard P. Gabriel. "Lisp: Good News, Bad News, How to Win Big." AI Expert (June 1991), pp. 31-39.
[2] James O. Coplien. "A Generative Development-Process Pattern Language." Pattern Languages of Program Design. Addison-Wesley, 1995, pp.183-238.
|