InfoQ Homepage Presentations Pimp My Architecture
Pimp My Architecture
Summary
Dan North discusses an example of rearchitecting an application without rewriting it from scratch, and explains general strategies for a holistic rearchitecture such as changing the team culture, removing obsolete technologies, allowing mistakes to be made (and learned from), transitional architectures, introducing bounded contexts, refactoring and emergent simplicity, and rotating through roles.
Bio
Dan is a principal consultant with ThoughtWorks, where he writes software and coaches teams in agile and lean methods. He believes in putting people first and writing simple, pragmatic software, and that most problems that teams face are about communication. This is why he puts so much emphasis on "getting the words right", and why he is so passionate about BDD, communication and how people learn.
About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community. QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
Community comments
Excellent talk
by Paul Fremantle,
Ok....nothing much to take away
by Sushil Kumar,
My favourite of Dan's talks
by Elizabeth Keogh,
Wrong title
by Emeka Kanu,
Good Stuff Here
by Richard Ruge,
great stuff - for developers, too
by Gergely Nagy,
Favorite
by Sonja Threadcraft,
Slides...
by Richard Fearn,
Excellent talk
by Paul Fremantle,
Your message is awaiting moderation. Thank you for participating in the discussion.
Excellent talk. Thanks!
Ok....nothing much to take away
by Sushil Kumar,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hear this ramble on about da..da..da.....no real concrete takeaways.
My favourite of Dan's talks
by Elizabeth Keogh,
Your message is awaiting moderation. Thank you for participating in the discussion.
I love this talk because as well as teaching a bit about enterprise application architecture, the messes that can be created and some alternatives to that mess, it teaches about the people which create that mess, treating a team with respect and leveraging their enthusiasm for change effectively. IME that's a harder thing to get right than the actual architecture.
Worth watching just for Dan's description of singletons.
Wrong title
by Emeka Kanu,
Your message is awaiting moderation. Thank you for participating in the discussion.
This talk seems to be focusing more on good software development management rather than good architecture. Yes there are the architectural benefits that he talked about. But as a developer, I'm getting more lessons as to how to be a good team leader in the future, rather than being a good architect....No offense
Good Stuff Here
by Richard Ruge,
Your message is awaiting moderation. Thank you for participating in the discussion.
'ello 'ello. I thought the discussion was great for the Sr Developer to Architect. This is not about architectural design practices. It's all about selling a good or better software architecture; i.e. pimp = sell. Whether that's to a team, CIO, CEO, whomever. A lot of the time we have a great idea that never gets used for all the reasons that Dan gives in this discussion.
Peace, Richard
great stuff - for developers, too
by Gergely Nagy,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think there are great thoughts here even for us, "developers".
As Dan points out: the first problem is *not* the lack of technical experience of the colleagues (like knowing design patterns for example, he says most of the guys were skilled enough) but the whole approach, culture, mentality.
That's much deeper than just managers' BS - it's about the real -pragmatic, agile- nature of the software development (rather than the rigid separation of developers/bosses, silos in the Waterfall model).
Maybe more details on techniques wouldn't hurt, but that would have made this much longer - yet, what's said there was a necessary minimum. There just too many of those techniques, and those can be better covered in books like "Design Patterns", Refactoring, TDD, "Working Effectively with legacy code",etc..
Favorite
by Sonja Threadcraft,
Your message is awaiting moderation. Thank you for participating in the discussion.
Excellent. Thanks Dan & InfoQ.
Slides...
by Richard Fearn,
Your message is awaiting moderation. Thank you for participating in the discussion.
...can be found here.