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
- March 2012 (2)
- 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…
- Talman Stoner on How far should you look ahead?
- Talman Stoner on Agile Architecture Myth #5: Never Look Ahead
- John Schwartz on Agile Architecture Myth #5: Never Look Ahead
- Rebecca on Agile Architecture Myth #5: Never Look Ahead
- Chris Collins on Agile Architecture Myth #5: Never Look Ahead
Author Archives: Rebecca
How far should you look ahead?
I’m a consultant. So an easy answer would be, “It depends.” My real answer is more nuanced: only look ahead far enough to see some significant issue and a plausible way to resolve it. If you want to get better, … Continue reading
Posted in Agile, Software Architecture, Software Design
1 Comment
Agile Architecture Myth #5: Never Look Ahead
Stop it! Stop anticipating! Get coding. Get that next user story working. Don’t. Ever. Anticipate. This seems to be a common agile mantra these days. Since we allegedly aren’t good at anticipating how code will evolve, well frack it, let’s … Continue reading
Posted in Agile, Software Architecture, Software Design
Tagged agile design, anticipation, design, looking ahead
4 Comments
What is Pragmatic Testing All About?
-Rebecca Wirfs-Brock and Joe Yoder We’re excited to be offering a new course, Pragmatic Test-Driven Development, with a practical bent to testing. Test-driven development (TDD) traditionally means writing unit and acceptance tests along with production code. Some agile thought leaders … Continue reading
Posted in Uncategorized
Leave a comment
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
Re-thinking Thinking and Planning
In the tutorial, Hooray We’re Agile Testers! What’s Next?, Janet Gregory apologized a couple of times for saying upfront thinking or planning. I know Janet wanted to let the audience know that she isn’t a fan of massive test plans … Continue reading
Posted in Agile
Leave a comment
Who Defines (or Redefines) Landing Zone Criteria?
Who should be in on discussions that set landing zone criteria? Because most landing zone have architectural implications, someone knowledgeable about the system architecture, in addition to the product owner and other key stakeholders should have a lot to say … Continue reading
Posted in Agile, Requirements, Software Architecture
Tagged facilitation, landing zones
Leave a comment
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
Agile Landing Zones
In my last post I introduced the idea of landing zones, a set of criteria used to monitor and characterize the “releasability” of a product. A landing zone contains system attributes that must be achieved to declare “success”, along with … Continue reading
Posted in Agile, Requirements
Leave a comment
Introducing Landing Zones
On an aircraft carrier, the landing zone describes a small section of deck that a pilot must touch down in to land the plane safely. By analogy, a landing zone for a product describes a range of measurable attributes that … Continue reading
Posted in Agile, Requirements, Software Architecture
Leave a comment