Talkin’ about…
acceptance tests agile use cases antipatterns AONW apologies assumptions Christopher Alexander communication customer service data and algorithms design for test design patterns design roots documentation drawing driven meme DSLs emergent design Eric Evans fun habitable software icebreaker IEEE design column index cards JAOO living software OOPSLA open space parametric polymorphism PLoP podcast problem frames Responsibility-Driven Design SD Best Practices software development processes software history structured design TDD teamwork terminology test-driven development travel use cases wizard-of-oz prototypes workshopsPast Entries
- September 2011 (1)
- August 2011 (5)
- July 2011 (3)
- May 2011 (1)
- February 2011 (1)
- January 2011 (1)
- December 2010 (1)
- July 2010 (1)
- April 2010 (2)
- October 2009 (1)
- August 2009 (1)
- June 2009 (2)
- March 2009 (1)
- January 2009 (1)
- November 2008 (1)
- September 2008 (1)
- August 2008 (2)
- June 2008 (1)
- April 2008 (1)
- February 2008 (2)
- November 2007 (1)
- October 2007 (1)
- September 2007 (1)
- June 2007 (1)
- May 2007 (1)
- April 2007 (3)
- February 2007 (3)
- January 2007 (1)
- September 2006 (2)
- August 2006 (2)
- July 2006 (2)
- June 2006 (1)
- April 2006 (2)
- February 2006 (3)
- January 2006 (3)
- November 2005 (4)
- October 2005 (7)
- September 2005 (1)
- July 2005 (3)
- June 2005 (5)
- May 2005 (3)
- April 2005 (2)
- December 2004 (2)
Reactions…
- Who is Rebecca Wirfs-brock | Yves Hanoulle on Little things add up
- Rebecca on An Architect’s Dilemna: Should I Rework or Exploit Legacy Architecture?
- Simon on An Architect’s Dilemna: Should I Rework or Exploit Legacy Architecture?
- J A Schwartz on Can you really estimate complexity with use cases?
- J A Schwartz on Agile Architecture Myths #1 Simple Design is Always Better
Category Archives: Software Design
An Architect’s Dilemna: Should I Rework or Exploit Legacy Architecture?
I recently spoke with an architect has been tuning up a legacy system that is built out of a patchwork quilt of technologies. As a consequence of its age and lack of common design approaches, the system is difficult to … Continue reading
Posted in Software Architecture, Software Design
2 Comments
Agile Architecture Myths #4 Because you are agile you can change your system fast!
Agile designers embrace change. But that doesn’t mean change is always easy. Some things are harder to change than others. So it is good to know how to explain this to impatient product stakeholders, program managers, or product owners when … Continue reading
Landing Zone Targets: Precision, Specificity, and Wiggle Room
A landing zone is a set of criteria used to monitor and characterize the “releasability” of a product. Landing zones allow you to take product features and system qualities and trade them off against each other to determine what an … Continue reading
Posted in Agile, Requirements, Software Architecture, Software Design
Tagged landing zone, target values
Leave a comment
Software Decision Making Under Stress
I recently blogged about my discomfort with making software design decisions at “the last responsible moment” and suggested that deciding at the “most responsible moment” might be a better approach. To me, a slight semantic shift made a difference in … Continue reading
Posted in Agile, Psychology, Software Design
2 Comments
Agile Architecture Myths #2 Architecture Decisions Should Be Made At the Last Responsible Moment
In Lean Software Development: An Agile Toolkit, Mary and Tom Poppendieck describe “the last responsible moment” for making decisions: Concurrent development makes it possible to delay commitment until the last responsible moment, that is, the moment at which failing to … Continue reading
Posted in Agile, Software Architecture, Software Design
1 Comment
Agile Architecture Myths #1 Simple Design is Always Better
Over the next few weeks I plan to blog about some agile software architecture and design beliefs that can cause confusion and dissent on agile teams (and angst for project and program managers). Johanna Rothman and I have jointly drawn … Continue reading
Posted in Agile, Software Architecture, Software Design
11 Comments
Draw a Tree
I often use a short, icebreaker to introduce design storytelling in talks and classes. I hand out an index card and ask people to draw a tree in 60 seconds. I’ve adapted this from Thiagi’s 99 second Draw a Tree … Continue reading
Posted in Software Design, Teaching techniques
Tagged assumptions, drawing, icebreaker, index cards
2 Comments
Design For Test
It sounds straightforward. Write your test code first, then write code to pass that test. Don’t write an inch of code without writing a test first. That is what test-driven development (TDD) is about: Use tests to drive out the … Continue reading
The Value of Design Documentation
Recently I asked students to tell me what kinds of requirements they start with and what (if any) design documents do they produce. Several students said that they produced documentation just because it was part of their development process. As … Continue reading
Sustainable Design
In my most recent IEEE Column, Creating Sustainable Designs, I explore what it means to create software that can be maintained without too many growing pains. I have been intrigued by Christopher Alexander’s writings, particularly the first two volumes of … Continue reading