Do it simply, quickly, and learn. Then go back and do it again.
Reading the "Quality" chapter in "Implementing Lean" book (our Tech Bible), I was really trying to overlay their prescribed development cycle over our recent projects, and see what things would be like if we had followed their prophecies to the letter.
Step One: Write Tests
We would be using TDD in a religious fashion. They begin each user story by writing test cases that need implementation in order to pass. We tend to write test cases as things start solidifying or (in the case of our Selenium tests (read: regression tests) we write them after customer delivery). In my next projects, I will be using TDD to see how it really works in our environment. More on that later.
With black-box testing (which, let's face it, is what you are doing in TDD), you have to think of not only the cases where "it should work", but also the cases where "it should not break". Very different. That is a challenge that I have had with Black Boxing -- you have to be very careful to think (read: pre-imagine) the different harsh treatment that your software will be enduring down the road. Suffice to say, it is *very* important that your TDD takes into account what you *don't* want your system to do as much as what you *do* want it to do.
Step Two: Solve in the Simplest Way
We would do the simplest thing possible to get the test cases passing. The idea is, if you write your tests cases correctly, then when they pass you are theoretically done.
A main component of Lean Development is "Delivering Fast". The faster your code is out there, the faster you can learn from it. The more knowledge you have, the better decisions you can make. Delivering Fast does necessarily mean making reckless decisions. Martin Fowler's Technical Debt Quadrant should help illustrate the concept that:
It is OK to Incur Technical Debt, *IF* it is Prudent
Delivering Fast means that you incur Deliberate, Prudent debt in order to gain the most knowledge the most quickly. Which leads to...
Step Three: Refactor
After "going into the hole", technically, you need to clean up after yourself so that it is obvious what the code is meant to do, and how it is meant to do it *and* so you do not have to pay interest on that debt down the road.
Martin Fowler's idea of Prudent, Inadvertent debt is a long term concept, where you do not necessarily even notice the interest you are paying until long after you took out the loan. This is not the situation that warrants immediate refactoring. Rather, it is the Prudent, Deliberate debt that you need to pay down. Let me say this, though:
Do not attempt Step Three without having done Step One
If you do not have good testing in place, refactoring can be both tedious and dangerous. And it is not supposed to be! Refactoring is supposed to be a no-sweat, "Now I see that this will be much easier to work with if we do it like this", post-learning experience. It should not be a "I hope I did not break something" experience.
The reason that The R Word is shunned in so many workshops is because they have legacy (read: un-tested) code. I know: I currently work in one!
Personal Take-Aways
I personally am admittedly, chronically, and (perhaps?) notoriously infamous for over-engineering situations. Some might call it a lack of common sense. Some might call it a dull Occam's Razor. Some might call it not "Seeing the Whole"
This means that I often fall into a trap that could be avoided by printing out this concept from the Implementing Lean book and taping it to my monitor:
Do it Simple *Then* Refactor!
How many times have you gone in to implement a user requirement and seen an opportunity for refactoring. So as you are implementing, you are refactoring with the "future implementation" in mind. And how many times have you realized, during this process, that you did not foresee a technical difficulty? And what does that mean: that neither your implementation nor your refactoring can proceed. Everything has to be reverted, and you have to go down the one-at-a-time path anyways. So start one-at-a-time from the very beginning!
So here's to doing the simple thing the first time. And to learning from it. And to cleaning things up when the situation warrants it.
Do it Simple, Stupid!
Hey what would it mean to you? To know that it'll Come back around again Hey whatever it means to you Know that everything Moves in circles -- "Circles" by Incubus
No comments:
Post a Comment