Brian Marick (see link on side nav) has been blogging about new metaphors for technical debt. He used "fertile assets", a gardening metaphor, which I like. If you don't amend the soil and plant your seeds at the right depth and weed thoughtfully, you won't get a good harvest. You might garden rather lazily like me and use ground covers and minimum tillage, but those are still good practices and produce good results. But if you let all the weeds grow up, it might be hard to remove them without damaging the good plants. Just like code that's hard to change if you don't have automated tests to tell you something got damaged.
I like Brian's metaphor, but to me, it's too positive. If we don't protect our code with tests, and don't refactor continually, and just hack in code changes without thinking, we won't just have a bad harvest, we might ruin the soil so it can't grow anything again.
I think technical debt is more like global warming. Lots of people claim it's just a myth and that we can ignore it. If I, as a tester, try to use good practices, but the programmers don't, it's like Denmark being green but not China. If everyone collaborates on a solution, emissions will go down quicker, and we will all breathe easier.
But, since global warming is a politically charged subject, it will get people arguing about that instead of thinking about how to make teams understand how shortcuts, poor design and lack of automation will grow an ever-larger burden for them to carry.
I'm now working on a metaphor that involves donkeys, perhaps log skidding. Recently my friends cut some small trees and branches near their creek bottom to make room for a bridge. We used the mini donkeys to haul the wood and brush over to the cabin's woodpile. If we tried to put too many logs in the bundle, or tied them so they dragged too much in the dirt, the donkeys had trouble pulling them up the hill. If we didn't take the time to tie them together well, they fell off. But when we took enough time to prepare optimally-sized, securely-tied, drag-dynamic bundles, we could make quick trips, and the woodpile grew fast. A little experimentation taught us that cutting corners didn't pay off.
Tuesday, August 19, 2008
Thursday, August 14, 2008
Testers can have an influence (so can anyone!)
We needed to do a story which had several tentacles, some into ugly parts of the legacy app. The story was basically to fix invalid data that's already out there, because business rules weren't enforced through the app.
Product owner never wants to "spend points", so he wanted just the very basic things that would get the immediate need resolved, and leave some other parts of the process manual. That means humans have to remember a lot of detailed, obscure business rules. That means in a couple of years, we'd get right back to where we are, with invalid data.
We do this sort of thing fairly often. It usually starts as "OK, just to get this out the door we'll do parts A and B, and we'll do C next sprint", but we never do C because the business can work around it by asking for manual updates to the database, which they seem to feel are "free". In fact, the very problem we were solving was caused by the fact that we never did the second part of a two-part series of stories, so a system requirement was just flung into a black hole.
I'm "only" (as some would say, not me) a tester, but I made my case. With fairly minor and inexpensive (say, 6-8 hours each) to 3 pages of the UI, we would prevent a lot of requests for manual updates later, and there was a high risk that the person doing the manual updates wouldn't know all the rules and would make an error. We'd also present the end users with valid data instead of, well, no data.
The product owner didn't like it much, but the developers saw the same problems I did, and wrote task cards for the three extra changes.
No matter what your main activities are on a team, if you see an issue, raise it, and present the problems and potential costs clearly. If your team can listen to reasonable arguments, you may be able to show them your point of view, and they'll likely agree with you. This shouldn't be adversarial in any way, but you can use your passion for delivering value to good effect.
We testers aren't here to be the Quality Police, but agile development should be about doing the right things "right". When you smell a hack, point it out and ask if it's reasonable to take the time to do it right.
Product owner never wants to "spend points", so he wanted just the very basic things that would get the immediate need resolved, and leave some other parts of the process manual. That means humans have to remember a lot of detailed, obscure business rules. That means in a couple of years, we'd get right back to where we are, with invalid data.
We do this sort of thing fairly often. It usually starts as "OK, just to get this out the door we'll do parts A and B, and we'll do C next sprint", but we never do C because the business can work around it by asking for manual updates to the database, which they seem to feel are "free". In fact, the very problem we were solving was caused by the fact that we never did the second part of a two-part series of stories, so a system requirement was just flung into a black hole.
I'm "only" (as some would say, not me) a tester, but I made my case. With fairly minor and inexpensive (say, 6-8 hours each) to 3 pages of the UI, we would prevent a lot of requests for manual updates later, and there was a high risk that the person doing the manual updates wouldn't know all the rules and would make an error. We'd also present the end users with valid data instead of, well, no data.
The product owner didn't like it much, but the developers saw the same problems I did, and wrote task cards for the three extra changes.
No matter what your main activities are on a team, if you see an issue, raise it, and present the problems and potential costs clearly. If your team can listen to reasonable arguments, you may be able to show them your point of view, and they'll likely agree with you. This shouldn't be adversarial in any way, but you can use your passion for delivering value to good effect.
We testers aren't here to be the Quality Police, but agile development should be about doing the right things "right". When you smell a hack, point it out and ask if it's reasonable to take the time to do it right.
Sunday, August 10, 2008
Thoughts on a Sunday
Why can't we Americans get a grip on how to reverse our energy problems? Thomas Friedman has a great column today.
And we could all step back and take a more generous, common-sense, and not-deathly-serious view of the world, like the Unitarian Jihadists.
I'm missing Tim Russert today.
Go, U.S. Dressage Team and especially Steffen Peters. The Chinese need to get their silly Olympic website working right, BTW.
OK, that's all off my chest, back to working on the final manuscript revisions for the Agile Testing book!
And we could all step back and take a more generous, common-sense, and not-deathly-serious view of the world, like the Unitarian Jihadists.
I'm missing Tim Russert today.
Go, U.S. Dressage Team and especially Steffen Peters. The Chinese need to get their silly Olympic website working right, BTW.
OK, that's all off my chest, back to working on the final manuscript revisions for the Agile Testing book!
Friday, August 8, 2008
Back from Agile 2008 - what did I learn?
Agile 2008 was hectic and I couldn't stay for all 4 days, so I know I missed out on lots of great ideas. However, I have the cd, and the phone-book-sized book of research papers and experience reports, which I can delve into as soon as we get done with our final manuscript revisions!
It's always so good to see the friends I only get to see once a year, as well as meet people I only know through the Internt. There were so many attendees this year, I didn't run into everybody I know, but great to see the ones I did run into.
I was reminded of how welcoming the agile community is in general, and what good people they are. One of my role models is Kay Johansen. She rocks because she's good at developing AND testing. She's both highly technical and great with people. Her workshops are always fun and super effective. She and her husband Zhon taught me mind mapping, which Janet and I have used to great effect to write our book. I'm looking at her materials from the "testing with a purpose" clinic she did at Agile 2008, and it reminded me that I don't focus enough on declarative testing, I get too involved in the "how" instead of the "what".
I met Patrick Wilson-Welsh this year because he asked me to help him with his tutorial on 'flipping the automated test triangle'. Patrick is such an engaging speaker, and he has a gift for fun group exercises - who else would think of having each group compose a Haiku about obstacles to automated unit tests? Like Kay, he is one of those quietly competent people, who is ready to learn from others. I loved hearing how he has been pairing with the developers at his current gig, letting them see he knows what he's doing, before helping them think of ways to improve. People learn a lot more from that than from some "expert" just coming in and telling them what to do.
And the best part about Patrick and Kay is they are two of the nicest people I know. So, I will strive to achieve their level of expertise and knowledge, while trying to help people as best I can, learning something from everyone.
Someone at Agile 2008 observed that there are lots of women at this conference, as opposed to, say, Oopsla, and wondered if it was because Agile creates an environment that women enjoy. I think there's a lot of truth to that. Myself, and most women I know, like the people side of things, we like collaborating with people. Sitting in a corner writing code by myself isn't my idea of fun. If agile development draws more women into our profession, so much the better.
It's always so good to see the friends I only get to see once a year, as well as meet people I only know through the Internt. There were so many attendees this year, I didn't run into everybody I know, but great to see the ones I did run into.
I was reminded of how welcoming the agile community is in general, and what good people they are. One of my role models is Kay Johansen. She rocks because she's good at developing AND testing. She's both highly technical and great with people. Her workshops are always fun and super effective. She and her husband Zhon taught me mind mapping, which Janet and I have used to great effect to write our book. I'm looking at her materials from the "testing with a purpose" clinic she did at Agile 2008, and it reminded me that I don't focus enough on declarative testing, I get too involved in the "how" instead of the "what".
I met Patrick Wilson-Welsh this year because he asked me to help him with his tutorial on 'flipping the automated test triangle'. Patrick is such an engaging speaker, and he has a gift for fun group exercises - who else would think of having each group compose a Haiku about obstacles to automated unit tests? Like Kay, he is one of those quietly competent people, who is ready to learn from others. I loved hearing how he has been pairing with the developers at his current gig, letting them see he knows what he's doing, before helping them think of ways to improve. People learn a lot more from that than from some "expert" just coming in and telling them what to do.
And the best part about Patrick and Kay is they are two of the nicest people I know. So, I will strive to achieve their level of expertise and knowledge, while trying to help people as best I can, learning something from everyone.
Someone at Agile 2008 observed that there are lots of women at this conference, as opposed to, say, Oopsla, and wondered if it was because Agile creates an environment that women enjoy. I think there's a lot of truth to that. Myself, and most women I know, like the people side of things, we like collaborating with people. Sitting in a corner writing code by myself isn't my idea of fun. If agile development draws more women into our profession, so much the better.
Friday, August 1, 2008
Agile 2008
Agile 2008 starts next Tuesday. Janet Gregory and I will do a tutorial Tuesday morning on "The Tester Who Came In from the Cold". We designed this tutorial in response to meeting so many teams where the programmers got trained in TDD and CI, the project managers all went to ScrumMaster training, but the testers were just left wondering what they were supposed to do on this new agile team. We'll give examples of how managers can help testers "come in from the cold", as well as how testers can help themselves. We have a cool exercise planned, we're pumped.
On Wednesday, I'll help Patrick Wilson-Welsh with his super tutorial on how to get your "test pyramid" right side up. Most new agile teams have the most test automation at the GUI layer, because those tools are usually easy for testers to learn, and the least at the unit level, because TDD is hard to learn. Patrick has added to Mike Cohn's test pyramid metaphor with a "three little pigs" reference. The unit level base of the pyramid is bricks, the behind-the-GUI middle layer is sticks, and the top GUI layer is straw. Of course you need GUI test automation, but it's usually the highest maintenance and the lowest overall ROI. He'll demo examples of tools for each layer. We'll both share stories of how our teams inverted their test pyramids. If time permits, we'll have a "micro open space" for participants to brainstorm how they'll go back and get their pyramids flipped around!
Please let me know if you'll be at Agile 2008. I'll only be there Tuesday and Wednesday (many conferences this year, a full time job and not enough vacation time!) but I'd like to catch up with as many friends (old and new) as I can. I'm especially looking forward to catching up with all the great agile Canadians (particularly those from Calgary!)
I've been to every XP, XP/AU, Agile Development Conference and Agile conference that's been held, starting with XP 2001 in N.C. I'm glad I'll make to Toronto! (I love Toronto too, wish I had more time to spend there...)
On Wednesday, I'll help Patrick Wilson-Welsh with his super tutorial on how to get your "test pyramid" right side up. Most new agile teams have the most test automation at the GUI layer, because those tools are usually easy for testers to learn, and the least at the unit level, because TDD is hard to learn. Patrick has added to Mike Cohn's test pyramid metaphor with a "three little pigs" reference. The unit level base of the pyramid is bricks, the behind-the-GUI middle layer is sticks, and the top GUI layer is straw. Of course you need GUI test automation, but it's usually the highest maintenance and the lowest overall ROI. He'll demo examples of tools for each layer. We'll both share stories of how our teams inverted their test pyramids. If time permits, we'll have a "micro open space" for participants to brainstorm how they'll go back and get their pyramids flipped around!
Please let me know if you'll be at Agile 2008. I'll only be there Tuesday and Wednesday (many conferences this year, a full time job and not enough vacation time!) but I'd like to catch up with as many friends (old and new) as I can. I'm especially looking forward to catching up with all the great agile Canadians (particularly those from Calgary!)
I've been to every XP, XP/AU, Agile Development Conference and Agile conference that's been held, starting with XP 2001 in N.C. I'm glad I'll make to Toronto! (I love Toronto too, wish I had more time to spend there...)
Subscribe to:
Posts (Atom)
