2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- September 3, 2015 ( 1 comments )
- Rants
In his book *Mythical Man-Month,* Frederick Brooks says to build a system “three times” by designing, implementing, and testing software. But this approach tends to amplify our mistakes rather than allow us to learn from them. It’s based on the false assumption that we can articulate a system’s behavior in the design documents with sufficient detail so as to make implementation merely a matter of following the design.
This has long been the dream of senior management because, as in building construction, the architect is a highly skilled (and highly paid) professional but the rest of the crew merely has to follow the directions outlined in his design documents. Construction workers don’t require a lot of specialized training and therefore don’t demand high salaries.
But software development is different. Requirements and design documents are not blueprints for software construction. In software, design and construction are inextricably linked. It can’t be separated out and a great deal of design decisions have to be made in the moment.
A much better approach is for developers to start by working through concrete examples. Examples give form to abstract concepts so they’re easy to think about, discuss, and find inconsistencies in. Working through an example isn’t a commitment to a particular implementation and it can give us lots of insights on how to best approach a design.
Working through a few examples gives developers enough perspective so they can form the right generalizations. This helps them find the right level of abstraction to apply when coding. And then, rather than launching into a testing phase to assure quality, we instead focus on cleaning up the code to *build supportability into the code we write* so we can continually improve our design and end up with a much better result.
-
Pingback: Five Blogs – 7 September 2015 | 5blogs
{1 Trackbacks }
Previous Post: « Playing All or Nothing
Next Post: Requirements Aren’t Required »