Software Engineering discussion

There are two themes in this chapter, both very relevant today:

1. How do you deal with the tradeoff between ease-of-use and functional richness? (Don't architect by committee, appoint one person to the task.)

2. How do you ensure that the architect is not the only person who has all the fun? (Don't worry, there is plenty of fun to go around.)

Question 1 is easier to state than practice. In my view, Apple succeeds because it knows that magic point where ease-of-use and rich function balance. If not actually architected by one (i.e. Jobs), their products at least appear to be.

I also agree that when unconstrained, engineers will tend to err on the side of too much function.

Brooks' separation of the "how" from the "what" is the basic definition difference today between "analysis" and "design".

I would agree that on a contained system, a single architect has great advantages. I think there are many cases where architect by committee is important such as standards groups (networks, formats such as video and email), etc... These examples generally require communication between systems.

Reading this book feels a little like reading poetry or classic literature, because I find myself trying to decode what I'm reading and looking for modern meaning. It's not hard to make this relate to my experiences, but effort is required.

I think that most successful architectures are a blend. They start with 1 or 2 people, become de-facto standards, and are then handed over to a standards committee to flesh out and maintain. It would be interesting to see a systematic historical look at this.