Thanks Larry, I enjoy our discussions.

1. Do you agree that we should strive to separate management processes from engineering activities? LM> Yes, and I think others will also. In particular, this issue has been hashed around in the agile community in the last few years, with many folks saying that XP is more collection of engineering practices, whereas Scrum (and others) are process definitions that focus on project management.

That’s good to hear. It’s not completely obvious they should be treated separately — there are plenty of places where they are tangled up but I think it’s a good aspirational goal to separate them. This means it may be possible to convince folks that architecture activities can be part of agile development, just like refactoring, which does not produce customer-visible product, but is a necessary to repeatably deliver value.

Altogether too often folks incorrectly assume that Architecture = Big Design Up Front (BDUF). I do not agree. I think of architecture as an engineering activity that you can do up front, in between, or later during refactoring. Of course there are things that are easier to decide in advance, like the architectural style of the entire system (e.g., client-server, REST, peer-to-peer, pipe-and-filter), but agile folks already agree with that too. As you say, choosing a framework such as J2EE or .Net can effectively decide your architectural style.

2. Do you think that components, connectors, etc. are effective abstractions? LM> No (sorry), but I don’t know enough to say conclusively. I should read your other draft chapters. Maybe starting with architectural patterns and considering components, connectors, and ports incidental would be more palatable for your book. I think most developers will prefer to use object-oriented terms and supplement that with OO design pattern terms when necessary.

You are right that most developers are thinking in terms of objects and design patterns. Interestingly, though, they weren’t thinking in terms of design patterns a decade ago (roughly) when the GoF book came out. Of course they were applying patterns informally and may have had pet names for them. The GoF book made a convincing argument that we should officially recognize what we’ve been doing already and give the patterns standard names. It also gave us a better handle by which to describe and compare potential solutions. Your short dialog about the developers is a great example.

There are striking parallels here with architecture. Only rookie developers consider functionality exclusively. Almost every project has some kind of internal divisions, be they clients and servers or various modules. We talk about the state of a protocol between two objects (or clients and servers). What’s missing here is that these ideas have not been reified and made explicit. When you say “component” you might be referring to a chunk of code, while I might mean a runtime chunk (e.g., you could have two runtime components as clients but just one compile-time module that has the source for them). Obviously we’d prefer to standardize some terminology. Being able to name architectural styles, which are just patterns at the architectural level, has the same benefits as naming design patterns.

You can solve the same problem thinking 1) just about the objects, or 2) by objects + design patterns, or 3) objects + design patterns + architectural abstractions. If you’ve got 5 objects, choose #1. if you’ve got 500 objects, #2 is still practical. If you’ve got 5000 objects, your brain starts to get full and you have to reach for #3.

We should probably be explicit about the hypothesis. One might be that “Objects are all you need”. Of course that’s easy to poke holes in, because we don’t strictly need objects. We could code in C or assembly. But we find objects a convenient abstraction. We think about objects rather than the machine code that makes them run. That way we free up our brains to solve the problem rather than thinking about registers and moving data between memory and the CPU.

Another possible hypothesis is that “Architectural abstractions like components and connectors can help us to understand large codebases”. We can quibble about what is large and if they are helpful or a nuisance on small codebases. I have done some work on big projects and my experience is that at some point you need to clump together big chunks of code. About 15 years of work has gone into defining and explaining the component and connector abstractions. They’re not perfect but they work better than 5000 objects.