Mas vale tarde que nunca

November 23 2011

8th Italian Agile Day has gone. funny, amusing, almost interesting and well-scheduled. I had positive feedback about my session too, even if we were just 30 people (it’s no surprise, being Francesco in the room next to us!). don’t forget, I collected resources about my session here, as usual.

I’m late answering one of the question from the audience: “how to successfully apply XP while still having to negotiate contracts with customers?”. my humble answer was: I’m not an expert in this field, but I can provide links to further readings. so here it comes!

resources in English:

resources in Italian:

I’m glad someone asked this during my session, this finally forced me to collect all those links in one single place! and sure I’m referring this blog post again, really really soon..


My results

February 1 2009

i’m 48 hours late. friday was the “results day”, as planned during the last Italian Agile Day. i’m one of the lucky ones, working in an agile team, both as a developer and a mentor too. but please, don’t think there’s no room for improving, nor for making mistakes: you’re wrong.

so, the bad things first.

i’m still too difficult to pair program with. i grab the keyboard from the driver’s hands not jut everytime my head has a new idea, but also when i see he/she’s doing a mistake. sometimes i “just” hit ESC from the navigator side whenever something wrong is coming. that’s truly, deeply, honestly wrong. i learned a lot from my mistakes, i should give a change to try (and fail too) to my team mate, in a timed-box fashion. even worse, my peer could have a simpler idea than mine, so why stop it? lesson learned: while acting as the navigator, tell your ideas first, and eventually grab the keyboard.

fine, now the good part!

one of the biggest risk on the project for our last customer was third-party services: API not yet ready, even functionalities unclear. for the mailing service, we were given an early WSDL to play with. it took a few days to develope a facade and an adapter to the system, in order to isolate our codebase from web services. even if it was incomplete (no way to send individual messages, just collective newsletters), we found out a simple way to send individual email: programmatically create a newsletter with a single recipient. managers told the team they asked for a complete API, “soon”. i think you can see… it never came, budget was over, time rushed. so, our simple but non optimized solution is now going to go in production, and it works. lesson learned: don’t anticipate change, it could take different paths than you thought, or it could never happen, at all.

then, i recently re-joined a previous project, after almost 5 months. so, my “fresh mind” helped the team spotting out some design smells. i’ve done a few code reviews and design spikes, checking out the codebase from scratch, and tried to let a “fatter” domain emerge, grabbing code from infrascture-poisoned areas. a strong re-packaging helped a lot, too. as a result, i put some note on paper, and took a nice screenshot of the packages structure. what followed were discussions and collective study sessions, during which we incrementally applied some of the hints, but better hints came out too, thanks to the whole team! design is now clearer and communicates better (even if we all know there’s a lot more to do). all the team members, also the newest ones, can now work on new user stories in a more confident way. lesson learned: focus on design.

and now, what’s next?

something i really missed during the last year is collective study sessions. i read and code a lot studying in my spare time, but i still miss gathering feedback from others. even if during a retrospetive the team decided to improve study sessions, i’m going to focus on timed-box collective brainstorming. in my view, design and refactoring are good candidates. that’s why i’ll push for an internal “Design Pattern Study Group”, or doing exercises from Wake’s “Refactoring Workbook” book.

being a team is tremendously different from being “a group of co-workers”. shared values, shared goals, respect, “we’re all in this together” approach. my suggestion to you, start thinking: am i working in a team or in work-group? feed a team culture, starting from values. i think results will come, soon: individuals and interactions over proesses and tools!

One year of presentations

January 11 2009

thinking back to what 2008 brought, one of the biggest news is me doing presentations, both at public agile events and at company seminars.

indeed, this summer me and Tommaso were at ESSAP doing a session on “Customer TDD and FitNesse”. then, in november Pietro and I were at the Italian Agile Day, presenting “Retrospective, Stand-up Meeting and Daily Journal”. then, just before xMas we had a company-wide webinar with me presenting “Testing in isolation pt.1, dependencies faking”.

doing mentoring also means having workshops and presentantions with other teams, so this year i also had the chance of presenting TDD, OO principles and mocking tools.

and, last but not least, i’ll be presenting in a few weeks at next italian Alt.NET conference (hosted by Sourcesense – more on this soon) talking, again, about Customer TDD and FitNesse, this time providing examples in .NET (even if the main theme remains the same).

being a developer does not help in any way presenting technical stuff in public. of course, a solid unterstanding ot the topics is mandatory, but knowing and telling are two completely different things. that’s why, doing and doing again, i finally hope to learn presenting in a clear and effective way. and improve my english too.

audience’s feedback is tremendously important!

Not sure? Write a test

November 5 2008

today i was pair programming with a developer (in my no-more-so-extended mentoring activity). i joined her desk while she was fighting with a complex test (reflection stuff) on a huge object mapper (about 200 fields). i already told her some days ago that, maybe, there could be a way to split it.. nevemind, today the issue was with the test.

first thing i suggested was trying to find which part of the test was wrong, so we started “refactoring” the test moving one piece in a separate helper class and test it in isolation. [i said “refactoring” because there was no green bar when we started. it was like working with legacy code, which you wuold like to refactor, having no test at all.]

i know, maybe it sounds strange to test the test (as the Latin said, “Quis custodiet ipsos custodes?”), but i found many times it’s a good way to get feedback on what’s going on, expecially when you’re “developing” a base test class, instead of extracting it from existing test code.

so, we had a green bar on a simpler scenario: mapping a custom object (a two fields DummyObject class written just beside the test) with the super-magic-reflectionist helper class. then we put some complex field into the dummy and added assertions to the test. bingo! a red bar on the screen, telling us that, probably, we found a way to reproduce in a smaller scenario what was the failing cause.

dilemma: was the tested code bad or the test itself poorly written? i had no idea (i was very very tired, but pleased of someone asking for my help), neither she. when i’m completely lost, i need some feedback, in order to say “ok, this piece works, that doesn’t”. so i asked my mate “are the test data correct? do you think this Map contains a value for X?”. as she said “obviously no!”, i exclaimed “well, let’s write a test!”

what a surprise when we had a failure on assertFalse(mappedValue.containsKey(".."))!

it was now clear: the test was wrong. what we then did is not so interesting (basically, write a simpler and correct test and have it pass, then move back to the original scenario). the focus in this story is on using the tests as a way to gather feedback, whatever you’re doing: coding, testing or spiking.

many developers don’t see the value in testing as a feedback tool. they prefer to code and debug. in my opinion, debug is a powerful but exhausting techinque, that’s why i use it only in emergencies – when there’s no other way.

my mate for today, very smart, she sometimes make fun of me because everytime she ask me for help, i always ask her for any running tests, otherwise i start writing one. anyway, i hope sooner or later she’ll start writing test-first herself. get test-infected.