Engineering activities vs. management activities
This is a letter to my friend Larry Maccherone, who is an expert on software processes and Agile in particular.
Larry,
Here’s something I’d like your opinion on, and it might become another blog post for you. I believe we should try to understand engineering activities separately from management activities. It’s tough to disentangle them, but regardless of management process you’ll need to decide what the system should do, assign responsibilities to parts, and think about (analyze) if indeed the thing you designed/coded will do what you were asked functionally, and if it will have acceptable qualities (performance, modifiability, etc.)
I also believe that success depends on aligning the management and engineering activities. XP and other agile practices are actually a nice merging of the two. Engineers on space systems may be forced into waterfall processes (you can only launch a rocket once) and XP developers may use iterative processes (you can relaunch the website each week), but both have the same engineering vocabulary — processes, modules, analyses, tests, etc. My goal with the architecture book is to help popularize the software architecture ideas (mostly the CMU/SEI versions of those ideas) and help them become de facto standards across all engineers/developers. For example, Szyperski’s definition of a component is pretty different from the CMU/SEI definition, and his book is not so old. My book is actively trying to avoid promoting a particular management process but instead showing that the core engineering ideas and activities are compatible with a variety of management processes (agile in particular), but that doesn’t make the book title “Agile Software Architecture”.
I hate to think of a situation where two trained engineers are at a whiteboard trying to solve a problem and they do not have the right abstractions / models to think about and solve their problems. Sure, they’re bright, so they figure something out ad hoc from first principles and some fuzzy intuition about chunking large bits of software. But I’d like them to have a standardized, shared vocabulary of parts (components, connectors, protocols, properties, etc.) that are effective for understanding the problems they face. (That’s the “abstractions” part I discuss in the book’s introduction). And over time we’d be more effective at sharing our solutions (which is the “knowledge” part from the intro) the way design patterns were a success. Right now, most folks have a hard time seeing that the styles used in operating systems are effective there, and the styles used in IT systems are effective there, but a client-server OS or a CSP billing system is probably a bad match. Another example of this is folks arguing that “your language is stupid”, because it’s not a good match for problems from a different domain (e.g., Java is probably not the best choice for OS device drivers and ditto for C and billing systems).
I’d be happy to hear your thoughts on any of this, but in particular on these questions:
- Do you agree that we should strive to separate management processes from engineering activities?
- Do you think that components, connectors, etc. are effective abstractions?
- Do you believe the majority of developers understand these abstractions?
Regards,
-George
