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
Tag Archives: IEEE design column
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
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
Design Hygiene
Without ongoing attention to design hygiene, design integrity is bound to deteriorate over time. My latest IEEE design column, Enabling Change, briefly examines what it takes to keep a code base ready to absorb new design changes. At the very … Continue reading
Posted in Software Design
Tagged emergent design, IEEE design column, refactoring tools, refactorings
2 Comments
Giving Design Advice
In an ideal work environment software designers freely ask for and offer constructive criticism and openly discuss issues. They don’t take criticism as personal affronts, and they and their managers make intelligent, informed decisions. OK, so how do design discussions … Continue reading
Posted in Psychology, Software Design
Tagged cognitive biases, design advice, IEEE design column
4 Comments
Martin Fowler is no Kent Beck
I know the difference between those two….When authors make mistakes, readers notice. In my latest IEEE Software Design Column, Driven…to Discovering Your Design Values, I quoted Martin Fowler as claiming that test-driven development, “gives you this sense of keeping just … Continue reading
Start Me Up…
…it’s a new year and time to exercise my blogging muscles. I’ve been hunkered away writing design columns for IEEE Software (as well as enjoying a holiday break). Now that two columns are in the bag, I am turning some … Continue reading