• Skip to main content
  • Skip to after header navigation
  • Skip to site footer

Shaping Software

Enduring Ideas in the Realm of Software

  • About
  • Topics
  • Best Software Books
  • Archives
  • JD Meier.com

Periodic Design Refactoring

Jun 23, 2008 by JD

In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maiden mention periodic design refactoring:

A variant of the Incremental model appears to be the ‘Extreme Programing (XP)’ approach put forward in Beck (2000) in which integrity of the system architecture across all increments is maintained by periodic design ‘refactoring.’

While I’m not a fan of Big Design Up Front, I am a fan leveraging the following techniques up front to help reduce risk:

  • System stories up front (where system stories include the ‘ilities and quality attributes, such as performance, security, reliability, … etc.)
  • Architectural spikes (time-boxed exploration to do some focused, end-to-end tests around high-risk areas)
  • Candidate architectures
  • Tests for success

I think these lightweight techniques help avoid dead-ends and help you figure out what you know, don’t know, and need to know next.

Category: ArchitectureTag: Agile, Architecture, Design, Techniques

About JD

Previous Post:Mission Impossible
Next Post:Visual Threats and Countermeasures

Reader Interactions

Comments

  1. Gerald Williams

    Jul 13, 2008 at 8:41 am

    This also ties in with the emergent architecture http://www.scrumlabs.com/2008/07/emergent-architecture-yes-or-no/

    and technical debt http://www.scrumlabs.com/tag/technical-debt/

    debates that I have been having with myself 🙂

    I agree with your points on leveraging techniques.

  2. Gerald Williams

    Jul 13, 2008 at 8:43 am

    I agree with your leveraging techniques quoted.

    This whole area ties in the emergent Architecture and Technical Debt debates.

    http://www.scrumlabs.com/2008/07/emergent-architecture-yes-or-no/
    http://www.scrumlabs.com/2008/07/technical-debt/

    Thanks.

  3. JD

    Aug 18, 2008 at 1:01 am

    Hey Gerald

    These are lessons learned from the school of hard knocks. I’ve seen projects that couldn’t see the forest from the trees, as well as projects that discovered too little too late. I’ve also experienced projects that did too much up front planning that turned out to be wasteful, over-engineering.

    In today’s market, the key is to cast a wide net up front, identify your key risks, and spiral down, staying flexible and adaptable along the way. In other words, expect the unexpected, and don’t try to plan for every exception. Have a vision, but be able to refine it as you go.

Trackbacks

  1. A Functional Skeleton of the System as a Whole says:
    Aug 18, 2008 at 1:07 am

    […] Periodic Design Refactoring […]

Sidebar

Recent Posts

  • What is ChatGPT?
  • Agile Performance Engineering
  • What is Cybersecurity?
  • Software Security Threats: A Comprehensive Guide
  • What is Software Security?

Popular Posts

Best Software Books of All Time
Best Practices for Project Management
Best Practices for Software Development
Customer-Connected Engineering
How To Frame Problems Better
How To Pitch Business Ideas Better
How To Structure Vision Scope Presentations
Intro to Lean Software Development
Lean Principles for Software Development
The Enterprise of the Future