2024 Public Training Schedule
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
- October 19, 2016
- Bits and Pieces
One difference I see between the Waterfall projects I used to work on and the Agile projects I work on now is that my desk is much less cluttered now.
A lot of traditional software development methodologies require additional artifacts: UML diagrams, flowcharts, design specifications, UI layouts, the list goes on and on.
The Agile Manifesto says “working software over comprehensive documentation.”
But many development methodologies require several additional documents in the process of building their software. Individually, these additional artifacts may not seem like much but over the course of a development cycle these additional items can become a burden.
Every artifact has its purpose, but treating all documents with equal importance can be wasteful and unnecessary. A design artifact has its purpose. Design artifacts are valuable during design and implementation. Once a design document serves its purpose and is no longer useful it should no longer be updated.
Ultimately, the goal is to produce valuable software and software is the ultimate expression of complex processes. The asset that we are being paid to build is the software and the only reason we create additional artifacts is to aid the creation or usage of that software. I encourage developers to minimize the amount of artifacts they use and “think with their hands.”
Thinking with your hands means writing code. I used to think it was irresponsible to just jump in and start coding before I had a complete set of requirements but now I find it’s easier to start simple and only build what’s needed now.
Rather than using lengthy requirements documents I prefer a few well selected examples that I can work through with my Product Owner or customer. This usually gives me the right level of feedback to build a feature that’s useful to them.
Twenty-five years ago I subscribed to Brook’s “build a system three times.” I would design on paper then implement in code and then test all the software I created. But this approach wasn’t giving me three opportunities to improve my system. Instead I found I was improving three different sets of constraints on what I was doing. Today I let systems emerge by first writing a test for the behavior I want to create and then making that test fail. Next I implement that behavior so the test succeeds.
I typically do very little design up front. Instead I let implementation details emerge through refactoring so I end up with working code and an automated suite of unit tests. This gives me the platform to sculpt the code into the design I want and I can do it safely because all the code is already under test.
One of the big benefits of ending up with a suite of good unit tests that support code is that it clearly documents how the code is to be used and we always know that those tests are up to date by running them and verifying that they still work. This provides a level of assurance that our tests are in sync with our code. This kind of assurance is not available from any other artifact except automated tests, which makes those automated tests not just advantageous to have, but in my mind essential.
Previous Post: « Version Everything!
Next Post: Rearrange the Furniture »