- RestrospectiveTechniques compiled by George Dinwiddie
- Agile Retrospectives Resource Wiki
- Singing the Songs of Project Experience: Patterns and Retrospectives by Linda Rising and Esther Derby from Cutter IT Journal (PDF)
- Restrospective Agility by Tim Mackinnon in Objective View (PDF)
- http://www.retrospectives.com/ Norm Kerth's website.
- Esther Derby's
- Rachel Davies'
- Sample chapters 3 & 5 from Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen:
- Ellen Gottesdiener's Team Retrospectives — for better iterative assessment looks at the topic from a RUP perspective.
- Bill Wake's Some Patterns for Iteration Retrospectives
- James Carr's Retrospective Patterns
- Ian Burgess' Agile Retrospectives Lessons Learned
- Ilja Preuss' Retrospective Anti-Patterns
- Article: Leveraging Agile Retrospectives to Evolve Your Architecture
- Simon Baker on Retrospective Using Appreciative Inquiry (see similar article by Diana Larsen)
- Ben Coombs' A Retrospective based on Agile Values
- Mark Levison's Agile Games for Making Retrospectives Interesting
- Kris Blake's Retrospective Agenda for High-Performing Teams
- Scrum Alliance - Seven Ways to Revitalize Your Sprint Retrospectives
- Fabio Periera's Goal-Driven Retrospective
- Mishkin Berteig's Agile Work: Cheat-Sheet for Retrospectives
- Agile Journal - Iteration and Release Retrospectives: The Natural Rhythm for Agile Measurement
- Retrospectives Content on InfoQ.com/retrospectives, including ...
- InfoQ: Heartbeat Retrospectives to Amplify Team
- InfoQ: Making Retrospective Changes Stick
- InfoQ: How Long Should Retrospectives Last?
- InfoQ: First (Forgotten?) Rule Of The Retrospective: Follow Through
- InfoQ: Annotated Burn-Down Charts Help During Retrospectives
- InfoQ: Frequent Retrospectives Accelerate Learning and Improvement
- Jim Shore's brief recap and retrospective format from The Art of Agile Development (0596527675)
Sunday, July 26, 2009
Friday, July 17, 2009
PART II - REFACTORING @ SCALE
- To scale refactoring for larger projects, some additional techniques & issues must be added to the mix.
- Note that this is “in addition to” (not “instead of”)
|Refactoring In-the-Small||Refactoring @ Scale|
|Small, Fast & Frequent Refactorings||Larger, Periodic & Planned Restructurings|
|Emergent Design||Incremental Design & Evolutionary Architecture|
|Deferred Refactoring||Restructuring & Technical Debt|
|Code Smells||Architecture Smells|
|Design Principles & Patterns||Software Modifiability Tactics|
|Simple/Clean Code||Supple/Domain-Driven Design|
2. Emergent Design
- Emergent Design is a fancy name for the resulting design that “emerges” from the synergy of combining Refactoring together with TDD, Continuous Integration and Automated Testing.
- Emergent Design means that ...
4. Restructuring Technical Debt
- If we accrue a non-trivial amount of technical debt, we can’t simply “refactor” it away.
- Paying it off typically requires restructuring efforts (or even reengineering) that must be planned.
- Iteration plans must accommodate specific tasks for these restructuring efforts (or even be dedicated to restructuring).
- Ignoring it, or deferring it for very long is not a viable option!
- Identifies higher-level issues (“architecture smells”) that typically represent violations of known principles of good software architecture & design.
- Periodically applies larger-scale “refactorings” and/or many small refactorings that were previously deferred.
- The goal is to “pay down technical debt” in order to limit the increasing costs of accumulated complexity.
- Typically requires a concerted effort that must be separately planned.
- Uses not only design patterns/principles, but also architectural patterns/principles, as well as software modifiability tactics.
- See Martin Fowler's description in Refactoring Malapropism
- Restructuring is often associated with absent or neglectful refactoring and/or design.
- But … Any large software project spanning multiple teams eventually needs restructuring.
- Even in the presence expert-level architecture, design & continuous refactoring
- This is just a reality of software evolution/entropy
- Therefore … Large software projects should assume that periodic restructuring will be necessary, and should plan accordingly to:
- Clean-up accumulated code-smells and apply numerous refactorings that were deferred but are now sorely needed,
- Address architecture smells by applying restructurings, patterns and modifiability tactics that have broader impact.
See Stefan Roock's and Martin Lippert's book Refactoring in Large Software Projects (There was an earlier version of their work entitled Large Refactorings").
- Smells in Dependency Graphs
- Smells in Inheritance Hierarchies
- Smells in Packages
- Smells in Subsystems
- Smells in Layers
- Localize Changes (increase cohesion)
- Prevent Ripple Effects (reduce coupling)
- Defer Binding-time (defer decision-making)
11. Evolutionary Architecture
- Software Architecture concerns infrastructure elements that must exist before you can begin execution.
- Architecture is about things that are hard to change later, it is difficult to allow an architecture to emerge.
- For large projects, this includes high-level organization of the system into functionality/elements that will be allocated to separate teams.
- Key techniques of Evolutionary Architecture include:
- Deferring Irreversible Decisions to the “Last Responsible Moment” (LRM Principle)
- Architectural “Spike”, Architecture Iteration and/or Spike Iteration
- Design evolves incrementally, iteration by iteration, based on current business priorities and discovered technical limitations.
- Incremental Design …
- Does not prohibit thinking about higher-level design.
- Does encourage planning in detail only what will be constructed soon.
- Focus is on “Just Enough, Just-In-Time” :
- Specifying too much detail too soon causes more rework later.
- But doing less now and saving the rest for later should not require significantly more work later than it would today.
- We must do Just Enough Design Initially to attain the right balance of anticipation and adaptation.
- Initial design (before coding) is still necessary.
- This use of “JEDI” was coined by Stephen Palmer as part of Feature-Driven Development (FDD)
- Basic rule of thumb to tell when “JEDI” is achieved:
- At iteration-scope, when, after one pass through the iteration backlog, modeling in small groups does not produce any new classes or associations of real significance.
- At task/TDD scope, when we have defined enough structure & interface(s) to know specifically what code to write/test, precisely where to write it, and exactly how to invoke it.
- Techniques of “the JEDI way” include:
- Domain-Driven Design (DDD) approaches modeling the core logic of the software by focusing on the domain.
- The basic idea is the design should directly reflect the core business domain and domain-logic of the problem to solve
- This helps understanding the problem as well as the implementation and increases maintainability of the software.
- DDD uses common principles and patterns as "building blocks" to model & create a "supple design”
- Supple: pliant, malleable, limber, yielding or changing readily.
- The design is firm yet flexible, with structure and intent both clearly conveyed and deeply realized by the code.
- Patterns of Supple Design include: Intention-Revealing Interfaces, Ubiquitous Language, Side-Effect-Free Functions, Assertions, Conceptual Contours, Standalone Classes, Closure of Operations, Declarative Style
Resources on Emergent Design and Evolutionary Architecture
- Neal Ford, Evolutionary Architecture and Emergent Design series of articles on IBM developerWorks:
- Emergent Design: The Evolutionary Nature of Professional Software Development, by Scott L. Bain
- Architecture in an Agile Organization by Chris Sterling (online)
- InfoQ: Michael Stal on Architecture Refactoring
- Refactoring in Large Software Projects: Performing Complex Restructurings Successfully, by Martin Lippert, Stephen Roock (also an earlier version online)
- Object-oriented Reengineering Patterns, by S. Demeyer, S. Ducasse & O. Nierstrasz (freely downloadable online)
- Technical Debt and Design Death:How to ensure you can deliver business value in the future as well as in the present; by Kane Mar and Michael James
- Design debt economics: A vocabulary for describing the causes, costs, and cures for software maintainability problems;by John Elm, IBM developerWorks, June 2009
- Managing Technical Debt and 10X Software Development - Technical Debt, by Steve McConnell
- Managing Technical Debt; by Tom Brazier
- Repaying Technical Debt; by Simon Baker
- Software Debt: Depreciation of Value for Software Assets and Technical Debt: Reducing Internal Quality for Short-term Gain, by Chris Sterling
- Software Entropy: Don’t Tolerate Broken Windows, and Zero-Tolerance Construction by Andy Hunt and Dave Thomas
- Modifiability Tactics, SEI @ CMU Technical Report CMU/SEI-2007-TR-002
- Modifiability Tactics, Chapter 5 section 3 of Software Architecture in Practice
- Understanding Architectural Patterns in Terms of Tactics and Models
- Design and Tactics, Lecture notes from an
course on Database and Software Architecture Aalborg University
- Wikipedia page on DDD
- DDD Intro Article
- DDD – a Brief Introduction
- DDD: Supple Design Patterns
- DDD Pattern Summaries
- Free mini-eBook: Domain-Driven Design Quickly
- Yet another free mini-eBook: Step-by-Step Guide to DDD
- See also domaindrivendesign.org and infoq.com/domain-driven-design
Thursday, July 16, 2009
Here is an outline and some thoughts for part I of some slides ...
PART I - REFACTORING FOR AGILITY
1. Overview of Refactoring
- Identifies design-maintenance issues (“code smells”) that typically represent violations of known principles of good design.
- Incrementally and iteratively applies a set of design improvement techniques (“refactorings”).
- The goal is to minimize complexity & duplication in order to maximize simplicity & ease-of-change.
- Encourages the “right” design details to emerge “just-in-time” with minimal guesswork/rework.
- Scaling-up includes the use of periodic restructuring, initial & incremental design (“just enough”), and evolutionary architecture.
2. Refactoring Defined [cite definition(s)]
3. Refactoring Myths -- Refactoring is NOT …
- “Rework” – redesigning things that could, and should, have been designed correctly in the first place.
- Design “gold-plating” – work that adds no business value, and merely serves to stroke the egos of perfectionists who are out of touch with business reality.
- Miscellaneous code “tidying” – the kind that is “nice to have,” but should only happen when the team has some slack-time, and is a luxury we can do without, without any serious consequences.
- A license to “hack” – avoiding any and all initial design & analysis and instead jumping straight to coding with no “real” design.
- Reengineering – large-scale restructuring that requires a concerted effort over the course of several weeks/months to re-write or re-architect significant parts of the system.
- A systematic approach to source-code “hygiene” that minimizes the chances of introducing bugs
- Improving the design of the code after it has been written
- A behavior-preserving transformation of source-code structure
- The process of simplifying & consolidating a work-product by making several, small, successive revisions focused on: preserving correctness, removing redundancy, revealing thoughts & intentions, and improving clarity & conciseness.
- A disciplined way of making changes while exposing the project to significantly less risk.
- An effective means to address the economic reality of software growth/complexity by reducing & amortizing its cost throughout the daily business of code development & maintenance activities.
6. How to Refactor
7. Rules of Clean Code
8. Rules for Simple Code
9. The Steps of Refactoring
10. Code Smells
11. Categories of Refactorings
- Small Refactorings
- Larger Refactorings/Restructurings
- Each category contains as many as a dozen or more refactorings, most of which are catalogued at http://refactoring.com/catalog/
12. Refactorings (Some refactorings from real projects)
- See http://refactoring.com/catalog/ for an up-to-date list (and the “Refactoring to Patterns” catalog too)
- I spot a “smell” that is not already known or catalogued?
- There is no specific known/catalogued “refactoring” for what I think I need?
- While adding functionality
- While fixing a bug
- While reviewing code
- After coding the same/similar thing for the third time (to “factor out” the duplication)
- A.k.a.: The Rule of Three: 3 strikes and you refactor.
- After the third time you deferred refactoring a change, for any reason [The Rule of Three, again]
- Before the end of the iteration if you haven’t been following The Rule of Three
16. When NOT to Refactor?
- When the build is broken or tests don’t pass
- When it would compromise meeting an impending deadline or commitment
- When the code in question really just needs to be re-written “from scratch”
- When it would modify code/interfaces that could significantly impact/break other work (e.g.: Published/public interfaces and protocols, Database schemas/tables/operations)
- Sometimes we must defer refactoring for later and/or plan for subsequent restructuring
Software Design Principles and Design Patterns are the underlying foundation for Refactoring:
- Code smells (a.k.a “code pathologies”): Signal a possible violation of design principles, Suggest which refactoring may be needed
- Refactoring: Correct a design principle violation (at least partially), Converge toward common design patterns
- Design Patterns: Reconcile forces among conflicting design concerns,Restore balance between competing design principles
- Design Principles: Lead us to attain desired design qualities/attributes
Qualities of Highly Maintainable Software:
- Loose Coupling & High Cohesion
- Hierarchy (Structural Decomposition)
- Abstraction, Encapsulation & Modularity
- Sufficiency, Parsimony and Primitiveness
- The SOLID Principles of Object-Oriented Design (from Uncle Bob)
- The SoC Principle: Separation of Concerns — separate interface from implementation, policy from mechanism, behavior from construction, commands from queries, ...
- The DRY Principle: Don’t Repeat Yourself (Eliminate Duplication), Single Point of Truth
- The “Structure-Shy” Principle: (“Tell, Don’t Ask!”), The Law of Demeter, Principle of Least Assumed Knowledge
- OAOO – Say Things Once And Only Once (restatement of the DRY principle)
- DTSTTCPW – Do The Simplest Thing That Could Possibly Work! (restatement of the KISS principle)
- YAGNI – You Aren’t Gonna Need It!
- The LRM Principle: Defer Commitment of Irreversible Decisions to the Last Responsible Moment!
- BDUF – Big Design Up-Front! (vs. JEDI)
- JEDI – Just Enough Design Initially/In-front!
- DDD – Domain-Driven Design
22. Summary: Refactoring for Agility
- Successively applies small behavior-preserving transformations to eliminate code smells
- Based on proven design principles and patterns for achieving maintainability & modifiability
- Good automated testing is a prerequisite
- Refactoring is not rewriting, rework or restructuring
- With refactoring, we continuously invest nominal effort to reduce the risk & cycle-time of changes
- The goal is to minimize complexity & duplication in order to maximize simplicity & ease-of-change.
- Practiced in a highly disciplined manner, it promotes:
- Sufficient functionality
- Simple & clean code
- Supple design
- Serviceable software
- Sustainable team velocity
- Introduction to Code Smells and Refactoring from TestingEducation.org
- Code Smells and Refactoring to Patterns, by Josh Kerievsky
- Refactoring and Code Smells
- The original WikiWiki CodeSmells page
- Martin Fowler's Code Smells page
- A Catalogue of Bad Smells in Code, by Martin Fowler and Kent Beck
- A Taxonomy of Bad Code Smells
- CodingHorror.com's list of Code Smells
- Smells to Refactorings Quick Reference, by Josh Kerievsky
- Gene Garcia's mapping of CodeSmells to Refactorings
- Using Static Analysis Tools to Identify Code Smells, IBM developerWorks article by Paul Duvall
- S.O.L.I.D. Principles e-Book (free) http://www.lostechies.com/content/pablo_ebook.aspx
- An O-O Primer, http://www.rgoarchitects.com/Files/ooprimer.pdf
- The Principles of Object-Oriented Design: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
- Design Principles and Patterns, http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf and http://www.oodesign.com/
- The Art of SoC (Separation of Concerns) http://www.ctrl-shift-b.com/2008/01/art-of-separation-of-concerns.html
- Tell, Don’t Ask, http://www.pragprog.com/articles/tell-dont-ask
- O-O in One Sentence: Keep it Shy, DRY, and Tell the Other Guy! http://media.pragprog.com/articles/may_04_oo1.pdf
- Online Resources:
- Wikipedia on Design Patterns
- The Patterns Home page: hillside.net/patterns
- Design Patterns Reference and Patterns Tutorials
- Patterns & Software: Essential Concepts & Terminology
- Design Patterns, by the “Gang of Four” (the book that started it all)
- POSA Series of books on Pattern-Oriented Software Architecture
- Head First Design Patterns, from the O’Reilly Head First Series
- Refactoring to Patterns; by Joshua Kerievsky
- Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin
- Implementation Patterns; by Kent Beck
- Design Patterns Explained (2ed); by Alan Shalloway, James Trott
- XP Simplicity Rules, http://c2.com/cgi/wiki?XpSimplicityRules
- Essential XP: Simple Design, http://www.xprogramming.com/xpmag/expEmergentDesign.htm
- DTSTTCPW - http://c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork
- OAOO - http://c2.com/cgi/wiki?OnceAndOnlyOnce
- YAGNI - http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It
- LRM - http://stevesmithblog.com/blog/delaying-decisions, http://vig.pearsoned.co.uk/samplechapter/0321150783.pdf
- BDUF - http://en.wikipedia.org/wiki/Big_Design_Up_Front
- JEDI - http://www.featuredrivendevelopment.com/node/507
- DDD - http://www.domaindrivendesign.org/
Tuesday, July 14, 2009
- Version Control with Git: Powerful tools and techniques for collaborative software development, by Jon Loeliger, O'Reilly, 2009
- Mercurial: The Definitive Guide -- Modern Software for Collaboration, by Bryan O'Sullivan, O'Reilly, 2009 (also see the online version at hgbook.red-bean.com)
- Programming Scala: Tackle Multi-Core Complexity on the Java Virtual Machine,
by Venkat Subramaniam, Pragmatic Programmers, 2009
For those who may not know ...
- Mercurial (like Git) is an open-source, distributed version-control system.
- While Scala is the "hot" new JVM-based programming language that not only contains the "best of both worlds" from other statically-typed languages (like Java) as well as dynamic languages like Groovy, but also the best of both worlds from object-oriented programming languages (OOPLs) and functional programming languages (like Erlang and Haskell). Plus it has message-passing and actor-based support for concurrency (like Erlang) while still being strongly typed and having access to all your favorite Java APIs (and anything else that compiles to JVM). Not too mention that Scala has a kick-butt Web development framework called Lift that is a next-generation framework to the likes of Rails/Grails and Apache Struts.
Scala is my first pick for the programming language that is most excitingly poised for the multi-core programming revolution in the age of multicore processors, cloud-computing, web 2.0 and access to all your favorite Java APIs/apps.
Saturday, July 11, 2009
A new book just came out that seems like the perfect complement to these two: Landing the Tech Job You Love by Andy Lester (also from the Pragmatic Programmers). I've only just started reading it but so far I like it a LOT! It also received a nice review by Mike Riley in DDJ online.
Rather than cite the blurb from the book this time, I rather like the description given in the press release:
It’s tougher than ever to get that great job. Companies are more demanding and your competition is smart, tech-savvy, and resourceful. You’ve got the right skills for the job—you also need the right skills for job hunting. You need to work deliberately on your new job hunting skills, and this book can help. Old fashioned cookie-cutter job hunting skills aren’t enough: Land the Tech Job You Love gives you the background and the hard-won wisdom to leapfrog those who play by the old rules.
Andy tells us, “Life is too short for a job you don’t love. You’re not stuck—other opportunities are available for you, if you know where to look and can work the hiring process to your advantage. This book will help you get that job you love.”
In this book, you’ll learn how to find the job you want that fits you and your employer. You’ll uncover the hidden jobs that never make it into the classifieds or Monster. You’ll start making and maintaining the connections that will drive your future career moves.
Andy started writing this book years before the recession (a.k.a. “econopocalypse”) hit. He looked at the conventional wisdom and the advice available in generic books on job hunting, and found the conventional wisdom just didn’t work for programmers, system administrators, testers, and other related development positions.
He looked at everything from whether you should look for work on online job boards to whether you should lead off your resume with your objectives. Although he has definite answers for these two, he found that the answer to most questions is “it depends.” His book leads you to taking an honest assessment of what you offer and what you want in a job so that you end up in a job that is a good fit for you and your employer.
This is an important book for you to read whether you currently have a job or not. The same tactics you take to make yourself more employable will also make it easier to get promoted in your current company.
Also see Andy Lester's presentation on Effective Job Interviewing from Both Side of the Desk and his blog @ TheWorkingGeek.com for his thoughts on "Job hunting and working life for programmers, sysadmins and all other techies"
Wednesday, July 08, 2009
The Economics of Iterative Software Development: Steering Toward Better Business Results is an important text for anyone trying to persuade management to "go iterative" as well as to anyone needing to measure & track the kinds of business results that management needs to see for a software development project.
I'll be perfectly honest: I was expecting this book to be an extremely dry and boring read, albeit full of lots of useful information densely packed in mathematical models and formulas, perhaps reminiscent of past college days reading a huge tome on socio-political economic theories. It wasn't as bad as I'd feared. Yes - it is a bit dry in places, but those are the exception rather than the rule. And there are lots of "war stories" sprinkled throughout that hold your interest and stop your eyes from glazing over.
All in all, The Economics of Iterative Software Development is a solid-book that is a relatively light/quick read with lots of good, practical advice on how to apply an economic model of thinking and measurement for managing and tracking business-results of an iterative project. If you need help doing that, or with communicating to your management about the need and benefits of an iterative approach, then you need to read this book!
See the full review for more details.
Monday, July 06, 2009
I think the "JEDI" approach is missing (any by that, I don't mean the mantra of "use the source Luke" ;-)
I think there is something missing regarding TDD and Design. Uncle Bob's three rules of TDD (and other writings) often mislead people to think that there is ZERO design up-front, as is if NOT doing Big-Design-Up-Front (BDUF) implies that therefore there is zero up-front design (NoDUF).
This is false (and Uncle Bob has even vehemently said so in The Scatology of Agile Architecture) but how does a newcomer reconcile it with the three rules of TDD? I can't write test-code without being able to invoke the thing-under-test. I can't invoke a thing if I haven't attempted to design the interface.
If I design an interface (even for a single method/subroutine) I have to have some inkling of which class/package/module it would go in, at least INITIALLY! There is some initial amount of design I do before writing a test that is both necessary and sufficient to define "just enough" of the interface of what I want my test-case to test.
So I think that is what is missing, a card called "JEDI", for "Just Enough Design Initially."
To my knowledge, this particular definition of the JEDI acronym in agile development was first used by Stephen Palmer and other FDD luminaries at www.step-10.com and featuredrivendevelopment.com (just do a Google-search on "JEDI" AND "Just Enough Design").
I also think there is a relationship between JEDI and Eric Evan's " Domain-Driven Design (DDD), Supple Design (part of DDD), as well as *some* of the so-called "Pre-factoring". But it can be a risky, slippery-slope, so it would be great to have some guidance to help us know when we've done "Just Enough Design In-front/Initially."
I suppose JEDI is a way of straddling the "appropriate range" of risk between anticipation and adaptation. I envision some kind of graph or diagram with axes ...
- On the left-hand side of overanticipating we have "too much too soon" and big/all up-front design.
- All the way on the right-hand-side we have "too little too late." Here you are faced with legacy-rewrites, system re-engineering, large-scale restructuring, etc.
- One Extreme does it by adding complex structures and behaviors too early in the cone-of-uncertainty and causes too much rework to rewrite that which was not yet certain and subject to much variability.
- The other extreme does it by sheer entropy/decay/rot that results from inattention and/or negligence
I imagine this "range" represents how to find the "sweet spot" that demarcates Just Enough Design Initially:
- In the middle of the scale is pure refactoring. It is strictly emergent, pay as you go just-in-time by focusing ruthlessly on keeping code clean and simple.
- Minor-to-moderate restructurings (too large to be refactorings, too small to be total re-writes) are to the right. Sometimes larger systems and/or systems constructed by multiple-teams can do a great job at refactoring and still not be able to avoid the need for minor-to-moderate restructuring, particular for aspects of the design that cut across teams and architecture and functionality.
- Just to the left of refactoring would be so-called "pre-factoring", where you have enough experience refactoring that you are able to apply basic application of encapsulation, DRY, separation of concerns, etc. without adding premature abstraction of inessential complexity. This is hard to get right, and has risk associated with it. But it does get progressively less with the better judgment that comes experience and practice.
- To the left of pre-factoring would be the subset of DDD known as Supple Design. And the rest of DDD would be to the left of supple-design.
The trick of knowing the "just enough" range lies not just in experience and discipline, but also in understanding your context and your "lead-time". Lead-time in particular dictates how soon in advance you need to be able to think and anticipate (and at what level of detail). The shorter the lead/cycle-time, the less you need to anticipate and prognosticate.
So I would see JEDI as a card that somehow is able to depict this continuum between anticipation and adaptation and where these various techniques fall on it, and the factors/tradeoffs that help you identify the right "range" for yourself. (And of course there is a close relation to technical debt and the cost-of-change curve :-)
Anyone ever seen a diagram that bears any resemblance to what I'm thinking of here?
Thursday, July 02, 2009
- Emergent Processes and Emergent Models of Architectural Practice, by Tom Wiscombe of emergentarchitecture.com
- Neal Ford's series of IBM developerWorks articles on Evolutionary Architecture and Emergent Design
- Chris Sterling's (upcoming) book on Architecture in an Agile Organization
- Articles on Emergent Architecture, from InfoQ.com
- Competing in the Era of Emergent Architecture: The Case of Packaged Software Industry, Proceedings of the 40th Annual Hawaii International Conference on System Sciences (2007)
- Any of the fine presentations by Ryan Shriver, over at theagileengineer.com
- Dean Leffingwell's writings on Agile Architecture and Intentional Architecture
- Jon Kern's Just Enough Early Architecture to Guide Development, from TechnicalDebt.WetPaint.com
- OOPSLA '09 workshop on "Architecture in an Agile World"
- Software Architecture and Agile Software Development - An Oxymoron? by Philippe Kruchten
- Agile Architect by Philippe Kruchten
- Is Design Dead? by Martin Fowler (see the section "Growing an Architecture")
- 97 Things Every Software Architect Should Know (the book)
- Extending an architecture as it earns business value by Alistair Cockburn
- Agile Architecture - How much is enough?, by Eoin Woods
- The Agile Architect site (including the role of the agile architect)
- Articles at blog.softwarearchitecture.com
- Agile Architecting by Erik Philippus
- Eric Evans' work on Domain-Driven Design, see in particular the DDD Pattern Summaries and the InfoQ eBook Domain Driven Design Quickly (also this Step-by-Step Guide to DDD)
- Scott Ambler's Scaling Agile Development via Architecture from the Agile Journal
- Lean Software Architecture, from Jim Coplien and Gertrud Bjornvig
- Agile Architecture and Agile Architecture Requires Modularity, by Kirk Knoernschild
- Product Line Architectures and Agile Development, M.Ali Babar et.al.
- Going Agile? Beware of Architecture-Related Changes and Challenges, M.Ali Babar et.al.
- The Evolutionary Architecture Practice from the Eclipse Process Framework
- DevJam's David Hussman on Architecture and Agility
- Architecture Meets Agility, by Hakan Erdogmus
- Toward and Evolutionary System of Systems Architecture, by Scott Selberg & Mark Austin, INCOSE 2008
- Guidelines for Lean Model-Based (System) Architecting and Software Engineering
- Systems Engineering and Architecting Challenges: Application to Agile Development, by Murray Cantor
- The (freely available online) book Object-Oriented Reengineering Patterns, by Serge Demeyer, Stéphane Ducasse and Oscar Nierstrasz
- The System Reengineering Patterns Project, by Perdita Stevens et.al. from Heriot-Watt University in Edinburgh (also see the SEI page on software reengineering)