BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations Pimp My Architecture

Pimp My Architecture

Bookmarks
54:57

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.

Recorded at:

Nov 12, 2009

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • 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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT