"Perfect is a verb, not an adjective" [1]

Learning new stuff is paramount in our line of work. I know, I know Cobol coders might tell you otherwise, and yeah, cobol coders might be home free, but the rest of us mortals need to keep up with the pace technology dictates. Or at least not to fall behind irreversibly much. Because then you might become the subject of Murphy's law, saying "If a hammer is all you have, everything you see will appear to look like a nail". It seems trivial, yet many software companies' don't seem to be sporting any learning or improving. Employers and employees alike seem to be confident in and/or content with their current experience and skills. Obviously it's extra effort short term to spend time and energy to learn new things, but with newer and better tools and techniques you can deliver better sotfware in shorter time. In fact the benefits and the profit are so plain to see, that it doesn't need any further explanation or examples, but then again this post would be ridiculously short.

Once you start looking up new stuff, or rather - because it might be something old - stuff you don't know, it becomes second nature, and you don't even notice all the advantages it gives you, or the way programming becomes easier with recently acquired knowledge. So it's difficult to pick any one example from our past year but I settled for mocking frameworks.
When we got to know TDD we dived into writing lots and lots of incomprehensible unit and functional tests nobody understood or was able to maintain. Then we stumbled upon mocking frameworks, and how we could live without one, beats the hell out of me now. We started to use Rhino Mocks, but soon enough our unit tests once again started to look like a can of worms, so this time intentionally searching for a cure, we found out about the AAA-concept (it's short for arrange/act/assert, but I can't find the exact link anymore; go google it up!). Finally we learned that we can use the lambda-expression to make our code even cleaner and readable. We learned and learned till unit testing and object mocking is less and less of a technical problem, and we can concentrate more on what we are trying to express and accomplish with our tests.
Again this example it's not even about new stuff, it's just stuff we hadn't known before. Keep learning and remember there are other useful tools than just the hammer.

References:
[1] Kent Beck: Extreme Programming Explained 2nd Edition

Read full post...

Transformers

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...

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...