This series aims to provide a fresh perspective on the often-discussed but elusive concepts of software architecture and design. Through concrete examples, Neal Ford gives you a solid grounding in the agile practices of evolutionary architecture and emergent design. By deferring important architectural and design decisions until the last responsible moment, you can prevent unnecessary complexity from undermining your software projects.
The first two articles in the series appeared today:
- Evolutionary architecture and emergent design: Investigating architecture and design
- Test-driven Design, Part 1
I plan to use this series to start a conversation about something that we all do everyday that we can't really describe well, even to other technical people (much less our grand parents). I don't supposed to know the answers (I'm not even sure I know all the questions), but at some point we have to talk about it. In the first installment, I provide some working definitions and some overarching concerns. Let me know what you think about it.
10 comments:
Hi Neil,
in your first article you quote a few definitions of architecture.
Here are a couple of neat ones I found in The Rational Unified Process: An Introduction (2nd Edition):
Architecture is what remains when you cannot take away any more things and still understand the system and explain how it works.
Architecture is part of the design; it is about making decisions about how the system will be built. But it is not all of the design. It stops at the major elements - the elements that have a pervasive and long-lasting effect on the qualities of the system, namely its evolvability and its performance.
Neil,
In your first article, you say:
"Technical debt resembles credit card debt: you don't have enough funds at the moment, so you borrow against the future. Similarly, your project doesn't have enough time to do something right, so you hack a just-in-time solution and hope to use some future time to come back and retrofit it."
Up to very recently, I would have considered this statement to be consistent with that of Ward Cunningham, who coined the term here, and that of Martin Fowler, who defined it here, but a few days ago Ward Cunningham posted a utube piece on the Debt Metapor which says (my paraphrasing of his words): 'many confused bloggers think the primary source of technical debt is writing code poorly, with the intention to do a good job later.
Does the utube piece change your understanding of technical debt?
Phillip -
No, it doesn't. Metaphors can change depending on the author -- when I use the debt metaphor, it's in the context that I wrote about (like Martin and Jared Richardson). I think Ward has a good take on this; I like his metaphor as well. However, in my defense, I never cast the "credit card" debt as quite as much of a straw man as Ward does. No one purposely writes bad code for the sake of bad code, but often external factors intrude on best intentions. In that way, I think that the debt metaphor works (at least for me).
Hi Neil
Both the articles are very well written. As a budding architect, i can corelate with what you say and find them useful.
Looking forward to the next in the series.
Thanks
This is really great stuff. The part about rampant genericness really struck a cord with me.
Very well written articles. I think the test-driven design supplements domain-driven design. It helps to uncover hidden domain concepts.
I'm looking forward to reading subsequent articles in this series.
Hi Neil,
First off thanks for a great start on the series - im really looking forward to the next.
I have to mention that getting the series on DeveloperWorks is absolutely brilliant. This will help many of us (with wall-to-wall IBM infrastructure) convince decision makers to try and drop BDUF.
I also hope you will take up this subject as a session, or series of sessions on the NFJS tour. It will make me cross the Atlantic to join up again for sure!
Hi, Peter -
The plan was/is to infiltrate from within. So far, so good...
I am in fact doing an "Emergent Design & Evolutionary Architecture" talk at No Fluff, Just Stuff this year. Hope to see you in some random city!
Post a Comment