Much of the agile literaure is focused on how difficult the transition from traditional to agile could be. They address the problem from many angles describing techniques how to help programmers to make peace with pair programming, how to get better at incremental design, some even suggest to use Organizational Patterns to introduce some of the practices to a team or a company. They all seem to be empathic with people who as a rule fear and loath change.
I don't see it that way. I actually think being a true "waterfall guy" helps you to accept agile, and helps you to execute XP practices and to a better outcome too(from this point on I'll be referring to XP, but probably most of what I have to say applies to other agile methodologies as well)
Having had been a true waterfall guy myself, with my precious UML diagrams, my very own modules and an ever strengthening habit of working alone on a laptop in pubs and cafes only occasionally checking in my work for my team to see, I had no problem at all transitioning to XP -- quite the contrary.
I enjoyed Pair Programming from Day 1, because I realised how much easier it is to pick one from the many possible ways to solve a problem, if you have someone competent to discuss it with. I learned not to fear to be stuck anymore, simply because it happens almost never, and even if it does, it's far less frustrating when you have someone next to you to share the pain. Becuse of all the implicit and explicit problems I had with the tradtional way, I appreciated Pair Programming a lot more then I would have otherwise.
To be able to do Incremental Design it's good to have had done a few BDUF yourself. It helps you to see the big picture - which some false interpretation of incremental desgin denies to be allowed - and it helps you to come up with sophisticated solutions quickly. But most importantly once you have seen first hand what's wrong with BDUF, you are ready to like Incremental Design for all of its benefits.
TDD is again something you appriciate more coming from a Waterfall world, because then you know how fustrating the bugfixing phase normally is, fixing and refixing bugs for months. You also know how frustraing and shameful it is not to make changes to code you hate and not to refactor at all due to either fear of breaking something, or an explicit order from your bosses, with something about changes are risky at this stage of the project, but the right stage for a change never seems to come. In which BTW they are absolutely right: without an extensive test harness, you can never be sure, even a little, that the changes you're about to make won't break the whole system.
All in all, the skills you learned and the bad experiences you had with waterfall all will make you a better agile developer.
Read full post...
Tuesday 29 December 2009
Tuesday 22 December 2009
Oil And Water, Or Are They?
Tester and developer couldn't be further apart, both of them fighting all the time without knowing any better. As one of our former tester put it, we have different goals: developers want the software to work, testers want it to break. For a long and regrettable time we shared this belief. But then we thought with agile it is over: bringing the tester closer to the team, both locationally and spiritually, would bring everyone to the same goal, i.e. to create quality software. It didn't work out as expected. Maybe the shared goal still wasn't shared enough, but I think we were missing a more important ingredient.
Fortunately we had learned our lesson, and with our new tester we tried harder. Once again Kent Beck helped us to find the missing pieces: Respect and Trust.
Though in his lecture he talks specifically about how trusty realtionship between developers and clients can help both parties to concentrate on creating values, I watched the inner workings of respect and trust in a tester-developer relationship.
In a timespan of a couple of 2-week iterations, our tester became a full-member of our team, thank to trust and respect. Quite rapidly we have arrived to the point where she trusts the developers enough to dare to ask them about the observed and expected behaviour of the system. She knows now she can be sure that a bug-candidate won't be dismissed due to programmers' arrogance or ego. She also knows she can freely ask all sorts of questions and won't be shushed or ignored or made fun of.
On the other hand we developers learned to respect her and her view on our software, and we learned not to discount whatever she has to say based solely on the fact that she didn't write the code, and in fact wouldn't even know how to.
Few minor, though important things at last. This productive relationship couldn't spring to life without our seriousness toward bugs: in an attempt to avoid the mini-waterfall effect we try to act quickly upon new bugs, this is not only practical from the technical point of view but also expresses respect, and thus strengthen trust. Unit and functional tests makes it possible that very few already working features break due to a fix of a new bug, again strengthening trust. Finally, our relatively fast build closes a very short feedback-loop of finding, fixing and retesting a bug creating a productive and positive atmosphere.
Read full post...
Fortunately we had learned our lesson, and with our new tester we tried harder. Once again Kent Beck helped us to find the missing pieces: Respect and Trust.
Though in his lecture he talks specifically about how trusty realtionship between developers and clients can help both parties to concentrate on creating values, I watched the inner workings of respect and trust in a tester-developer relationship.
In a timespan of a couple of 2-week iterations, our tester became a full-member of our team, thank to trust and respect. Quite rapidly we have arrived to the point where she trusts the developers enough to dare to ask them about the observed and expected behaviour of the system. She knows now she can be sure that a bug-candidate won't be dismissed due to programmers' arrogance or ego. She also knows she can freely ask all sorts of questions and won't be shushed or ignored or made fun of.
On the other hand we developers learned to respect her and her view on our software, and we learned not to discount whatever she has to say based solely on the fact that she didn't write the code, and in fact wouldn't even know how to.
Few minor, though important things at last. This productive relationship couldn't spring to life without our seriousness toward bugs: in an attempt to avoid the mini-waterfall effect we try to act quickly upon new bugs, this is not only practical from the technical point of view but also expresses respect, and thus strengthen trust. Unit and functional tests makes it possible that very few already working features break due to a fix of a new bug, again strengthening trust. Finally, our relatively fast build closes a very short feedback-loop of finding, fixing and retesting a bug creating a productive and positive atmosphere.
Read full post...
Monday 23 November 2009
The True Weight Of An Iteration Board
An iteration board carries lot more than its actual weight. It is there every day to remind you of all your mistakes and weaknesses. Sure, many people envy us for our friendly atmosphere and the unusually humane working environment we work in. What most people fail to see is our constant struggle to do our best. They don't see the cruel honesty that forces us to face our shortcomings day after day. There has not been an iteration, however successful, going by at the end of which we didn't identify issues in our process, approach or skills that we needed to resolve.
This honesty could be a real burden, especially for one with a programmer's ego, if you don't reach out to Kent's Principle of Opportunity, that states that we need to look at problems as opportunities. In this case as opportunities to improve.
Also don't forget, the problem is not the iteration board and its bug-cards for instance. Iteration boards and burndown-charts can solely be indicators of something going wrong, they are not the problem, nor the cause. So next time when you look at a burn-down chart that is not steap enough, or an iteration board that is not "green" enough, don't rush to find solutions to make it steaper, or don't try to organize your work, so that you can score more green points. Try to find the underlying problems, the more the merrier, forget your ego, and think of all the improvements you now have the opportunity to make.
Read full post...
This honesty could be a real burden, especially for one with a programmer's ego, if you don't reach out to Kent's Principle of Opportunity, that states that we need to look at problems as opportunities. In this case as opportunities to improve.
Also don't forget, the problem is not the iteration board and its bug-cards for instance. Iteration boards and burndown-charts can solely be indicators of something going wrong, they are not the problem, nor the cause. So next time when you look at a burn-down chart that is not steap enough, or an iteration board that is not "green" enough, don't rush to find solutions to make it steaper, or don't try to organize your work, so that you can score more green points. Try to find the underlying problems, the more the merrier, forget your ego, and think of all the improvements you now have the opportunity to make.
Read full post...
Saturday 7 November 2009
The Navigator
Pair programming is one of the key practices of XP, and so there is a lot to know and learn about it(which you can start by reading Pair Programming Illuminated by Laurie Williams, Robert Kessler). Let's focus on the navigator for now.
The navigator's role in my view is to look ahead: while the driver is to keep us on the road without any accidents, the navigator is to know where we're going and why, also what we're gonna do when we get there.
I figured that the best way I can accomplish this as a navigator is if I sit back and don't even watch what my driver is typing.
Don't get me wrong, it's not without merit when the navigator and driver don't talk much, just simply understand each other through bits of code and a few words, though this benefits the team more on the personal and social levels, helps to build mutual respect, team spirit and so on.
But the navigator's sort of turning away from the screen makes it imperative for him and the driver to start talking about the problems and solutions. A lot of good things can come out of saying something out loud. For instance you can realise you can't say it: it's too blurry to be said, and then chances are that your solution or your model of the problem is way too complicated. Other times when you try to explain your implementation out loud, you realise that it's just simply wrong.
In our praticular office layout there is another, quite relevant side effect of my turning somewhat away from the monitor: I get to see other parts of the room: the iteration board, the release board, the burn-down chart, our product manager, our tester, our build machine - all of which remind me to look at the problem at hand from many, different perspectives: all of which I might have forgotten about, had I watched my driver and his code unneccessarily closely...
So you can try it next time when you're the navigator and let me know how it turned out...
Read full post...
The navigator's role in my view is to look ahead: while the driver is to keep us on the road without any accidents, the navigator is to know where we're going and why, also what we're gonna do when we get there.
I figured that the best way I can accomplish this as a navigator is if I sit back and don't even watch what my driver is typing.
Don't get me wrong, it's not without merit when the navigator and driver don't talk much, just simply understand each other through bits of code and a few words, though this benefits the team more on the personal and social levels, helps to build mutual respect, team spirit and so on.
But the navigator's sort of turning away from the screen makes it imperative for him and the driver to start talking about the problems and solutions. A lot of good things can come out of saying something out loud. For instance you can realise you can't say it: it's too blurry to be said, and then chances are that your solution or your model of the problem is way too complicated. Other times when you try to explain your implementation out loud, you realise that it's just simply wrong.
In our praticular office layout there is another, quite relevant side effect of my turning somewhat away from the monitor: I get to see other parts of the room: the iteration board, the release board, the burn-down chart, our product manager, our tester, our build machine - all of which remind me to look at the problem at hand from many, different perspectives: all of which I might have forgotten about, had I watched my driver and his code unneccessarily closely...
So you can try it next time when you're the navigator and let me know how it turned out...
Read full post...
Friday 23 October 2009
Case closed
Many heated arguments about Test-Driven Development have certain recurring reasoning on both sides. In general, developers have a hard time accepting that they need to think differently about implementation and design and/or have to alter exisitng design in order to be able to write tests. "I would need to introduce this indirection only for testing" or "There is no need for this kind of hierarchy to implement the features in the production system", and their alikes are common critiques of TDD.
Inexperienced TDD people almost invariably try to tackle these with answers like "But your design will be better this way" or "Modularity is your friend" or "Indirection is a way to build flexibilty into your code".
Obviously all of these are correct and nothing new. SOLID for example is a well-known and universal set of principles supporting the answers above. However most of the defenders of TDD are missing the point.
The point is this:
Once we've agreed that unit testing is a very efficient way to create quality software and we want to do it, there is no room for further discussion. You just have to think about the testability of your code as any other requirement you have to implement. Don't worry, you will get all the earlier mentioned: flexibility, maintainability, comprehensibility, and so on. But that shouldn't have influence on this praticular matter, because you are required to write testable code anyway. There is really nothing else to it.
Once you can get your head around this, your life as an agile programmer will be much, much easier. Mine already is.
Read full post...
Inexperienced TDD people almost invariably try to tackle these with answers like "But your design will be better this way" or "Modularity is your friend" or "Indirection is a way to build flexibilty into your code".
Obviously all of these are correct and nothing new. SOLID for example is a well-known and universal set of principles supporting the answers above. However most of the defenders of TDD are missing the point.
The point is this:
Once we've agreed that unit testing is a very efficient way to create quality software and we want to do it, there is no room for further discussion. You just have to think about the testability of your code as any other requirement you have to implement. Don't worry, you will get all the earlier mentioned: flexibility, maintainability, comprehensibility, and so on. But that shouldn't have influence on this praticular matter, because you are required to write testable code anyway. There is really nothing else to it.
Once you can get your head around this, your life as an agile programmer will be much, much easier. Mine already is.
Read full post...
Saturday 17 October 2009
Traps Pt.1.: Rope-A-Dope
Many times in software development you have a simple problem, which has an easy solution. Or so it seems. You start solving the problem, but it turns out first you have to solve a different problem. Not a difficult one either, so you start working on it, but it's not long before you realise that before you could solve the second one you have to start with a third, all new problem. Again, not a very complicated one. Before you know it it's six o'clock in the evening, and you'd forgot all about the original problem, let alone solving it. Let's call it the Rope-A-Dope Trap. It's difficult exactly becuse it seems easy all the way. Every time just one small step away. There was just no point where you could have said no.
A possible escape from this trap is applying the Rule Of Three(or Two).
There are always obsticles creeping in when solving software problems, it's inevitable. But whenever you find yourself face to face with the third "creeper" in a row, you need to abort what you're doing, take a step back, a deep breath and a very good look at your original problem in light of the three unforseen ones. Rethink, regroup and start over. Starting over could mean a different approach, design, tool or even different requirements.
So watch out next time for a Rope-A-Dope. And don't forget that it could occur on many levels too. A method, a feature or a whole solution.
Read full post...
A possible escape from this trap is applying the Rule Of Three(or Two).
There are always obsticles creeping in when solving software problems, it's inevitable. But whenever you find yourself face to face with the third "creeper" in a row, you need to abort what you're doing, take a step back, a deep breath and a very good look at your original problem in light of the three unforseen ones. Rethink, regroup and start over. Starting over could mean a different approach, design, tool or even different requirements.
So watch out next time for a Rope-A-Dope. And don't forget that it could occur on many levels too. A method, a feature or a whole solution.
Read full post...
Subscribe to:
Posts (Atom)