Architecture is a secondary effect.
SDWest 2006 was a fun conference for me. I spoke every day except for Wednesday (when I flew to Philadelphia for a client meeting == thereby missing the Jolt awards.). I also attended a number of talks and sessions; the most notable of which was Mike Cohn's Planning and Estimating talk. Two of my talks were half-day tutorials on the PrinciplesOfOod. These talks were very well attended, and the response was enthusiastic.
Here are the slides from my talks.
| Advanced Principles of Class Design | What are the principles governing the composition and relationship between classes in an OO design. |
| Advanced Principles of Component Design | How do you compose and relate components in a large scale OO design. |
| The Prime Directive | A minimum level of professional behavior. |
On Thursday I conducted a round table on "Agility and Architecture". Lots of folks piled into the conference room until it was SRO. We put a list of issues on the flipchart and just worked through them all. My good buddy John Kern was there, and helped out a great deal. You can read about this session here.
One of the main points of that session was this:
- The main goal of architecture is flexibility, maintainability, and scalability.
- But we have learned that the kind of unit tests and acceptance tests produced by the discipline of Test Driven Development are much more important to flexibility, maintainability, and scalability.
- Therefore architecture is a second order effect and tests are the primary effect.
I had not thought about this before this round table. Here we were, a bunch of architects and designers, strongly debating the role and procedure of architecture, and the conclusion we come up with is that all the effort and struggle we go through results in a secondary improvement in flexibility, maintainability, and scalability. Writing tests (writing them first) has the primary effect.
This may seem a bitter pill to swallow. And many architects may reject it out of hand. However, nobody is suggesting that architecture is no important, or that we should throw it away in favor of tests. Quite the contrary. It is the tests that give us the fearlessness to continuously improve and the architecture of the system. It is not that tests supercede architecture; rather they enable it!
Automated tests give us a reliable way to know that our systems are working properly. Therefore we are no longer afraid that an architectural change will break them. This makes it much easier to enact those architectural changes that will improve the system. Therefore the presence of tests mean that there is much less impediment to continuous improvement of the structure, design, and architecture of a system.
Without tests, architecture was an initial guess that was difficult to change once significant development started. But with automated tests architecture remains malleable. The risk (and therefore the cost) of change is so greatly reduced that architecture becomes a variable that we can fiddle with as our system evolves.
!commentForm -r
Architecture should only be considered as a way to organise the goals and principles we wish to apply. We also want to keep track of the decisions we make in getting their. TDD may then be a methodology we choose to reach some of the goals or principles.
I calmed down. Still seriously cool stuff...
Hey Uncle Bob!
You seriously rule. 10 years ago you wrote these six fundamental articles in the C++ Report about good OOD. Basically, this is my bible of OOD. And I can find these principles again in your "Advanced Principles of Class Design" 10 years later (Advanced principle of class design ppt). This stuff is really built to last.
And btw I found out while doing mainly c++ work on linux, that debuggers sometimes are a wasteful timesink. It doesn't solve the hard problems, but its still a necessary tool sometimes.
Keep rolling!
You seriously rule. 10 years ago you wrote these six fundamental articles in the C++ Report about good OOD. Basically, this is my bible of OOD. And I can find these principles again in your "Advanced Principles of Class Design" 10 years later (Advanced principle of class design ppt). This stuff is really built to last.
And btw I found out while doing mainly c++ work on linux, that debuggers sometimes are a wasteful timesink. It doesn't solve the hard problems, but its still a necessary tool sometimes.
Keep rolling!
| Ismet: do you think aspects will dominate the industry and make obsolete what object oriented provided us? |
|Uncle Bob: No, I think Apects have had their day and failed to capture the imagination of the industry. There is no doubt that Aspects are cool; and that they have a wonderful ability to help manage dependencies. However, I think the Aspect movement never reached critical mass; and now I'm not sure if it will. Other issues are overtaking it, such as the growing popularity of Ruby and Rails.
You never know, the Aspect movement could re-energize. But that's not where I'd put my money in the short term.|
I beg to differ. At least in the Java world, AOP is becoming mainstream, driven by popular frameworks like Spring.
Additionally I believe that it is a misconception that AOP will replace or make OO obsolete; AOP complements OOP with respect to cross-cutting concerns.
I agree that that architecture without code to support it is useless (see for example my post http://www.rgoarchitects.com/blog/PermaLink,guid,a8251529-536b-44d8-87df-19e036d383b4.aspx)
However I think it is useless to write unit tests when you are still strugelling to define what the units are.
Code is the final design document - but the point/problem is working on large systems you need to work at higher levels of abstraction first to understand the picture. I do believe it is very important to get a skeletal architecture up-and-running as quickly as possibile (and writing it using TDD is probably the best way to go).
I think that until there will be usable ways to TDD in higher levels of abstraction - we will still have to go with design and test early
One more thing regarding "Automated tests give us a reliable way to know that our systems are working properly. Therefore we are no longer afraid that an architectural change will break them" - I think this has a limited effect. If caught on early stages (i.e. using the tests) the chages would be easier. An architectural change on later stages will still hurt. The test will "only" makes the impact analysis easier
Arnon
http://www.rgoarchitects.com/
However I think it is useless to write unit tests when you are still strugelling to define what the units are.
Code is the final design document - but the point/problem is working on large systems you need to work at higher levels of abstraction first to understand the picture. I do believe it is very important to get a skeletal architecture up-and-running as quickly as possibile (and writing it using TDD is probably the best way to go).
I think that until there will be usable ways to TDD in higher levels of abstraction - we will still have to go with design and test early
One more thing regarding "Automated tests give us a reliable way to know that our systems are working properly. Therefore we are no longer afraid that an architectural change will break them" - I think this has a limited effect. If caught on early stages (i.e. using the tests) the chages would be easier. An architectural change on later stages will still hurt. The test will "only" makes the impact analysis easier
Arnon
http://www.rgoarchitects.com/
| Ismet: do you think aspects will dominate the industry and make obsolete what object oriented provided us? |
No, I think Apects have had their day and failed to capture the imagination of the industry. There is no doubt that Aspects are cool; and that they have a wonderful ability to help manage dependencies. However, I think the Aspect movement never reached critical mass; and now I'm not sure if it will. Other issues are overtaking it, such as the growing popularity of Ruby and Rails.
You never know, the Aspect movement could re-energize. But that's not where I'd put my money in the short term.
Bob - Please write a book on Agile Architecture, or least a series of articles.
As you know, architecture is viewed by many as being missing from the agile perpsective.
The agile community (and consultants) would benefit from a compelling summary of agile architecture ideas, success stories, practioners, open source examples, etc. etc. I for one, see the list of agile advocates and have great faith in the approach. It sure would be nice to point to tons of data, examples, and stories from famous practioners in one book, or series. I'd even be glad to help in some way. If not you, who? A combination of arhitects? One chapter each: perspective, principles, examples?
As you know, architecture is viewed by many as being missing from the agile perpsective.
The agile community (and consultants) would benefit from a compelling summary of agile architecture ideas, success stories, practioners, open source examples, etc. etc. I for one, see the list of agile advocates and have great faith in the approach. It sure would be nice to point to tons of data, examples, and stories from famous practioners in one book, or series. I'd even be glad to help in some way. If not you, who? A combination of arhitects? One chapter each: perspective, principles, examples?
Great point about using testing to enable flexibility and drive architecture. If you go by the 'architecture is stuff that's hard to change' definition, I find using TDD really reduces the amount of architecture in my programs ;)
I think it's worth mentioning that the quality of your tests has a strong impact on the flexibility of your system. I've been on several teams that had good test coverage, but their 'unit tests' did not test components in isolation, and did not meet Michael Feathers' definition either. I believe that this was mostly because TDD was not applied (tests were written after significant portions of code, and often architecture, already existed). As a result, tests were large, very fragile, and very un-declarative. They did not enable easy architectural change. I think a lot of teams that are just starting to become agile miss out on the real flexibility that good tests provide because they are: 1) not doing TDD and 2) not creating real unit/isolation tests.
I think it's worth mentioning that the quality of your tests has a strong impact on the flexibility of your system. I've been on several teams that had good test coverage, but their 'unit tests' did not test components in isolation, and did not meet Michael Feathers' definition either. I believe that this was mostly because TDD was not applied (tests were written after significant portions of code, and often architecture, already existed). As a result, tests were large, very fragile, and very un-declarative. They did not enable easy architectural change. I think a lot of teams that are just starting to become agile miss out on the real flexibility that good tests provide because they are: 1) not doing TDD and 2) not creating real unit/isolation tests.
In your presentations, you did not mention the role of aspect oriented approach in dealing with change. This new(?) approach promises(?) crosscutting concerns, such as most of the architectural concerns, to be managed easily. Here is the question: do you think aspects will dominate the industry and make obsolete what object oriented provided us?
Looks that way to me at least.
Without the extensive test base of NxBRE (open source rules engine) I would not have been able to drastically refactor and improve the core of the engine as I did. I think that I have spent more time working on the tests (unit and acceptance) than on, say, optimizing the engine itself. With such an extensive coverage I ship new releases without loosing sleep (which could happen with such a critical component).
D.
PS. Thanks for the "Never Be Blocked" presentation, it was a truly great moment, you rocked the theatre!
D.
PS. Thanks for the "Never Be Blocked" presentation, it was a truly great moment, you rocked the theatre!
Add Child Page to ArchitectureIsaSecondaryEffect