Growing agilists

i know, i’m late, really really late.

6th Italian Agile Day has gone, on november 20th. as usual, it’s been a big party, when “old” friends meet and have fun, talking about Agile methods and Italian community. i was still sick, thanks to a friendly one-week flu, so i just reached at lunch time to avoid cold and rushing early in the morning. but it was enough! this year i dediced to “taste a bit of everything”, so i was able to join some open space and session, moving from one to another.

me and Davide also had a session on “Extreme Release Planning”, very funny for me: i had the pleasure to work with Davide, an ex-colleague of mine, and he had the idea of making the audience feel the problem we were talking about: loosing clear vision of priorities, due to lack of release dates. we set up a rudimental planning game: one long string with stories written on A4 sheets (with name and estimate), moving stories to another long string as soon as they were planned.

(thanks to the volunteer guys from adience for helping us with this!)

slides are available here.

here they are some good recap of the conference:

• Peter Stevens
• Jacopo Romei (in italian)
• Franco Lombardo (in italian)
• Emanuele DelBono (in italian)

as Roberto said on extremeprogramming-it mailing list, Italian Agile movement is growing and our conference has come of age!

see you next year.

Increment on the long term, iterate day by day

this is the transcription of the 10-minutes lighting talk i had last weekend during our company meeting in Amsterdam, which is based on the great article by Alistair Cockburn “Incremental means adding, iterative means reworking”. so, here it comes..

Incremental vs. iterative development

every project is big enough not to be completed just in one shot. so, we focus on delivering subsystems on a regular basis, e.g. one or two weeks. we face complexity with simplicity and feedback.

first strategy we can adopt is delivering complete subsystems, every week, splitting projects into small chunk of complete functionality, also known as user stories. we add features every other week: this is incremental development, the heart of every agile process.

in other words, we try to get it right in the first place, targeting quality for a final product.

another strategy is reaching the final product by revisions. we start from a rough prototype, and improve it by later adding details, till the final result. we do reworking: this is iterative development.

a great essay on the two strategies is Jeff Patton’s Monalisa example, as reported by Gojko Adzic on the waterfall trap.

back to the initial motto, here is my suggestion: even if you’re already doing incremental development, don’t forget to iterate. (it’s a shame the term “iterations” does not relate to iterative development, but to incremental development!)

why? because customer, not us, choose when to stop incrementing (adding) and iterating (reworking): you’ll be surprised by what a customer can consider good enough.

Time for an example

my team is currently working on an e-commerce website, and the customer asked for a complex checkout procedure: adding items to the shopping cart, mandatory login, shipping and billing addresses, payment details (e.g. credit card info), and finally a checkout with notification via email and to the reporting system.

during release and iteration planning, we first asked the customer to split the procedure into smaller user stories, so that we could understand and estimate with confidence. then, we started developing the most important ones; for example, no billing address nor reporting system notification were chosen.

this is incremental development.

one day was the turn of the shipping address user story: calculate shipping costs for each country (Italy has a fixed cost, other countries costs are taken from the database of our customer’s shipping company), displaying italian provinces when shipping to Italy, validating zip codes when in Italy (CAP). everything in a dynamic fashion.

having a lot of work to do, we decided to start with a minimal layout: a combo box for countries and a text displaying shipping costs for current country. it was far away from the final product, but gave us feedback that everything was working, from UI to database import script.

later, we decided to put two forms, for Italy and other countries, into the same page. that was an easy way for having a different layout and data for Italy. again, it would have probably not been the final product, but helped us focusing on designing UI and setting up data.

we finally moved on trying to understand how to dinamically change layout, based on current country. first idea was to use Javascript code client-side: something like having two hidden forms from which setting a third form’s innerHtml, and the like. we did a spike, but our result was not satisfying.

then, having our iteration going to end soon, we decided to propose to the customer a simpler way: an onchange event on the country combo box! dynamic, but server-side. it took one pomodoro for spiking a solution. then we just asked the customer, and after other two pomodoro of layout restructuring, it was done.

that was iterative development.

hope it does make sense to you: increment on the long term, iterate day by day!

About how pleasant a saturday can be

it all started at 6am.

yesterday i was in Bologna for the 4th Italian UGIAlt.NET conference. well, it was a very pleasant day: nice location, nice sessions, nice people, and finally a great social dinner. it also stopped raining just in time for open spaces to start, in the afteroon. so, we moved out in the garden just in front of the conference room and enjoyed fresh air sitting under the trees.

first of all, thanks to Roberto for the car journey and for being such a good friend.

so, here they are some notes i took during sessions.

Daniela started talking about designing User eXperience, focusing on prototyping as a way to let customer play and understand what he really needs, before producing functional mockups. it soon turned into a hot discussion about how to apply this approach to incremental software processes. as any upfront design activity, it’s clear how costly later changes could be. Daniela suggested the main cost is related to information architecture changes.
other notes:

• user-oriented process with early feedback
• UX scenarios really reminds user stories with acceptance criteria
• help a vocabulary emerge, like in Domain-Driven Design
• working on more wireframes in parallel requires continuos feedback from the team (daily), to achieve information integrity. as with standup meetings

then, it was Massimiliano turn talking about Mono, from a committer point of view! having shared also the journey with him, i can say for sure he’s a great computer science enthusiast. his session, very interesting, was about why the project began and it’s current goals. he then talked about current developing, such as for Moonlight (officially approved by Microsoft) and MonoDevelop. he shared some of the practices his team has: only a main stable trunk and branches for experimental features, strong health check with regression tests and a dedicated build farm for each target architecture.
here a few notes:

• two developing stacks: working on Windows vs. working on Linux. Novell chose the same strategy Microsoft did, reuse existing componenst, so suggested stack on Linux it’s a collection of wrappers: to GTK/Cocoa, to MySQL, and the like
• Java support powered by IKVM: just pay attention to how .NET AppDomains and Java Classloaders work
• something Mono gives you more: a micro-threading framework; a tool to bundle executables and framework together (mkbundle) on all supported platforms; an embedding API to achieve interoperability between Mono and native OS syscalls, cross-platform!
• licensing: LGPL for core (give back modifications to community), MIT for libriaries. Novell can do relicensing, mainly to big companies
• embedded Mono: highly optimized Mono packaging as an alternative to MS Compact Framework
• appliance tools: Novell provides a tool for making custom appliances as ISO or VMVare images
• application servers: that’s the most interesting one for me, looking for a valid open-source alternative to enterprise Java: mod_modo is a way, reusing Apache services as for security and balancing. Fast-CGI is another

after a rainy lunch, Simone started talking about ASP.NET MVC, a project to which he dedicated a soon-to-be-printed book. after a brief introduction to the framework and its goals (mainly, remove from WebForms the nasty postback abstraction!) he suggested some strategy to achieve controller-view data passing. examples were for a composed page where both summary (as for menus) and details are displayed. it was a very technical session, talking about “web/user-control” alternatives, and finally controllers and actions testability. funny enough, we noticed that while Microsoft finally got MVC (it’s 2009!) Java seems to go back to control-based web UIs like for JSF. i also won a nice t-shirt for a few interesting questions i asked!

then, the best session (in my view) started: Roberto talking about code metrics and refactoring on legacy code. he shared his current work experience on a huge Java codebase, with no test at all and big bosses asking for code quality numbers. he showed us metrics such as size, complexity, cohesion and coupling, and suggested no tool can say the whole truth until a contextual code review is performed. moreover, metrics should not be used to “grab” system state in a given time, but to evaluate system evolution during time.
he decided not to achieve quality in the immediate, because testing everything is costly and maybe a waste, but to use new functionalities on existing code to drive testing and refactoring. after having run tools on actual code and collected initial metrics, he spent a few week developing a mini testing framework to let characterization tests be written. those integration tests where written inspecting HTTP traffic with the system (a service in a SOA environment) talking to the database: he then prepared XML requests and expected responses and let tests compare expected with actual SOAP.
having integration tests, he started a mentoring activity with developers, studying OO priniciples, refactoring and unit testing. so, the team started writing unit tests for new and existing code, then refactoring. this was also driven by tools for code duplication detection. here some notes:

• the testing framework was easy to write: system already used Dependency Injection with Spring. he used testing facilities provided by Spring, such as automatic transaction rollback and auto-wiring
• he used a combination of open-source tools to export data from production database. thanks to the ORM (and no SQL in the application code), he imported data into an in-memory database, for testing
• documentation as a metric: this was asked by management, but he suggested code readability as an alternative
• refactoring smells and moves: turn comments into assertions; improper names suggest too many responsabilities, so extract code
• mentoring is more effective with examples taken from actual system code, instead of providing links to external articles and books
• start from testing and refactoring new code (then increase code coverage and remove duplication), instead of refactoring existing code (with no priority given)
• time spent testing and refactoring was soon payed off by time saved from manual deploy and verification. estimates were increased just by 20%. developers felt having much more time for developing

finally, i had the pleasure to drive an open-space in the garden with a dozen people or more. i started a discussion on team-building, taking notes on a flip-chart. my starting question was “how can we turn a workgroup into a team?”. people were interested, we talked about team values, dicipline and practices, and a comparison with sport teams such as in soccer. i just put ideas on this mind map:

conference organizers were very kind and decided to reward everyone proposed and drove open-spaces. my prize was a personal license for Balsamiq. Simone, Emanuele and Claudio: thank you guys!

finally, a special thank to all Bologna XUPG-ers for such a great dinner and for being so nice!

Collections algorithms as infrastructure

this week i’ve performed my first public kata, at the local XPUG, here in Milan. meeting’s topic was “internal iterators and blocks”, very close to my heart. i just had the idea a few days ago, and the eXtreme guys approved my session as soon as i proposed. (this year seems promising, a lot of pratical sessions planned… stay tuned!)

the main idea for a (code) kata is to perform a short pratical exercise you feel confident with, almost with no braining; fingers should go on smoothly, like a dance. i chose to start from Matteo’s “birthday greetings” session on exagonal architecture, as coded by Milo and me during an XPUG meeting. i did the kata at home a few times and collected on paper some guidelines. then i printed out “brief instructions”, which i distributed to the audience before starting. the plan was a three short exercises kata.

first, i refactored existing code, splitting loops, extracting the InternalIterator / Predicate pair and then moving construction to facades like On an Being. second exercise was adding a new functionality, “send a kiss to female employees”; i drove implementation with unit tests, and focused on using just extracted iterator and predicate code. it finally looked like this:

public class BirthdayService { ...

  public void sendGreetings(OurDate ourDate) throws Exception {
    List employees = employeeFacade.loadEmployees();

    for (Employee employee : On.items(employees).collect(Being.bornOn(ourDate))) {
      sendGreetingTo(employee, happyBirthday(employee));
    }

    for (Employee employee : On.items(employees).collect(Being.female())) {
      sendGreetingTo(employee, "A kiss for you");
    }
  }
}

then, the mini collections library – On.items().collect(predicate) – was first modified to be generic (with Java’s Generics) and then improved with other functionalities such as:

• findFirst(predicate)
• reject(predicate)
• contains(predicate)
• apply(transformation)

final code consisted of 3 interfaces for blocks, one class for internal iterator, a Not predicate implementation and, finally, the On facade.

the leitmotif for the session was “you know, i don’t really like algorithms, so i don’t want to write them twice!”. that funny sentence was just trying to show how much more readable and understandable the code was without noisy algorithm details (like useless foreach, if/else, results.add(), if not null, etc). even if it was late evening, audience was really following me (and i have to admit, i was going a bit too fast!). they also asked me some good questions.

Gabriele pointed out that maybe findFirst() should provide a default value parameter, instead or returning a null reference. with Roberto we also discussed how difficult could be to implement returning a generic NullObject instance. Matteo went further on the idea of literal programming, suggesting something like:

employees.collect(bornToday).do(sendGreeting)

this would require iterator returning another iterator instead of a collection, or encapsulating every collection into a domain object.

something that really catched my attention was Gabriele suggesting moving predicates from Being facade into domain classes, with the pleasant side effect of removing useless getters on domain objects. that’s really a good idea! i’ll consider this for sure next time (kata was insipired by code from a project i no more work on).

then, Matteo finally asked me how many “collection traverse” algorithms i would have encapsulated into an iterator. i could not answer, i thougth it depends on business scenarios. but i just didn’t understand well the question: he was referring to the foreach loops, and that’s why he suggested me that probably i would not have written another foreach loop, they’re just MAP and REDUCE (transform and collect). nice hint, i should study some more functional programming; or even better, some more Smalltalk-Rubysh idioms! (yes, i’ve done a Google search for that. first rule to learn more: admit your ignorance)

here it comes the best part. before going home, i pushed for this methapor. exagonal architecture (and DIP) promotes to encapsulate low-level infrastructure behind an interface (a facade), to which high-level client code interacts with passing around domain objects; you just have to write and adapter once. for example, an EmployeeFacade interface and a DatabaseEmployeeAdapter – written just once – which takes Conditions to filter data searches; new business scenarios can be achieved providing different Conditions, without the need to modify infrastructure code.

in the same way, i consider collection manipulation an infrastructure issue: what really matters is behaviour to be run on collection items. that’s why i really like writing algorithms just once, and reuse them heavly providing specific behaviour for a given user story: concrete predicates, transformations and other blocks are the only domain code i have to write; iterators are hidden behind a (creation) facade, like On.

when i first thought about, this sounded like an epiphany, but i can see it’s not so easy to understand, or to agree with. let me just know what you think about.

ok, and finally, here is the code! tests firts:

@Test
public void sholdCollectItemsMathcingAPredicate() throws Exception {
  assertEquals(Arrays.asList(2, 6), On.items(Arrays.asList(2, 3, 6)).collect(new Even()));
}

@Test
public void shouldFindAnItemMathingAPredicate() throws Exception {
  assertEquals(2, On.items(Arrays.asList(1, 2, 4, 5)).findFirst(new Even()));
}

@Test
public void shouldReturnNullIfNotMatchingItemFound() throws Exception {
  assertNull(On.items(Arrays.asList(1, 3, 5)).findFirst(new Even()));
}

@Test
public void shouldRejectItemsNotMathingAPredicate() throws Exception {
  assertEquals(Arrays.asList(1, 5), On.items(Arrays.asList(1, 2, 5, 4)).reject(new Even()));
}

@Test
public void shouldDetectIfAMatchingItemIsFound() throws Exception {
  assertTrue(On.items(2, 5).contains(new Even()));
}

@Test
public void shouldApplyTransformationOnEacheItem() throws Exception {
  assertEquals(Arrays.asList(2, 4, 6), On.items(1, 2, 3).apply(new Doubler()));
}

public class Even implements Predicate<Integer>{
  public boolean evaluate(Integer item) {
    return item % 2 == 0;
  }
}

public class Doubler implements SimpleTransformation<Integer> {
  public Integer applyOn(Integer item) {
    return item * 2;
  }
}

then application code:

public interface Predicate<TYPE> {
  boolean evaluate(TYPE item);
}

public interface Transformation<FROM, TO> {
  public TO applyOn(FROM item);
}

public interface SimpleTransformation<TYPE> extends Transformation<TYPE, TYPE>{
}

public class InternalIterator<TYPE> {
  private final List<TYPE> items;

  public InternalIterator(List<TYPE> items) {
    this.items = items;
  }

  public List<TYPE> collect(Predicate<TYPE> predicate) {
    List<TYPE> result = new ArrayList<TYPE>();
    for (TYPE eachItem : items) {
      if (predicate.evaluate(eachItem)) {
        result.add(eachItem);
      }
    }
    return result;
  }

  public TYPE findFirst(Predicate<TYPE> predicate) {
    List<TYPE> result = collect(predicate);
    return result.isEmpty() ? null : result.get(0);
  }

  public List<TYPE> reject(Predicate<TYPE> predicate) {
    return collect(new Not<TYPE>(predicate));
  }

  public boolean contains(Predicate<TYPE> predicate) {
    return ! collect(predicate).isEmpty();
  }

  public <TO> List<TO> apply(Transformation<TYPE, TO> tranfromation) {
    List<TO> result = new ArrayList<TO>();
    for (TYPE eachItem : items) {
      result.add(tranfromation.applyOn(eachItem));
    }
    return result;
  }
}

public class Not<TYPE> implements Predicate<TYPE> {
  private final Predicate<TYPE> predicate;

  public Not(Predicate<TYPE> predicate) {
    this.predicate = predicate;
  }

  public boolean evaluate(TYPE item) {
    return ! predicate.evaluate(item);
  }
}

public class On {

  public static <TYPE> InternalIterator<TYPE> items(List<TYPE> items) {
    return new InternalIterator<TYPE>(items);
  }

  public static <TYPE> InternalIterator<TYPE> items(TYPE... items) {
    return On.items(Arrays.asList(items));
  }
}

Working software

.. over comprehensive documentation.

yes, that’s one of the very clear sentences in the Agile Manifesto. but there’s more.

last tuesday i attended a presentation on Agile and XP Gabriele gave at the local Linux User Group in Cremona. the session was very good, people interested, a lot of discussion, me too, bringing my last two years experience. but please, always trust a geek saying “go on as long as you like, we can stay here ’till late night”: he’s serious!

Gabriele is a great speaker, i had never seen any of his presentations before. amazingly, in three hours and half, he just scratched the surface of common topics such as testing and refactoring, instead focusing on planning and (re)estimating.

i learned a lot too. mainly, my attention was caught by this sentence: “our main goal is not to develope software satisfying business requirements, our goal is to develope software our customer can gather value from”. in my view, this is the essence of any Agile development process, and, in fact, is also stated as the first principle in the manifesto too: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” (emphasis mine).

i spent a lot of time studying, learning, using and adjusting user stories acceptance tools, and helping developers understand how much “do the thing right” and “do the right thing” are different. but, even then, having all the acceptance criteria clear stated, is our job to verify them? do our customer pay us to do whatever he ask to?

definitively not. we get money to deliver software someone can make money with, or do something less costly with. or maybe, software doing something not feasible doing by hand. choose one. anyway, our job is to let our customer achieve his goals using our product.

for me, that’s really a context shift, and a daily challenge. i’m always focused on the internals of a system’s design, it’s architecture, how pieces work together. i live in an iperuranio where objects talk each other; where ideas born, live and evolve, and finally get real as working software. i’ve never paid much attention to what software is used for, i’ve always considered it a detail.

what a mistake!

from now on, contract i’ve signed as a developer is:

i’m allowed to imagine, design and construct the best (and simplest) system i can think of, as long as my goal is to deliver value to the customer.

working software over working acceptance tests!

Online italian Alt.NET conference video

thanks to Simone, last italian Alt.NET conference’s video are online.

so, are you tired? nothing on TV? girlfriend/boyfriend sick? maybe you could spend quite an hour with me talking (in italian) about acceptance tests and FitNesse.

Customer TDD and FitNesse at italian Alt.NET conference

as already posted a few days ago, next saturday i’ll be giving a presentation at the italian Alt.NET conference, hosted in Milan by the company i work for, Sourcesense. basically, it’s the same Tommaso and me gave at ESSAP last summer, but i’ve ported the basic examples in C#, packaged them all in a NAnt build script runnable both on Microsoft .NET and Mono. i’ve developed the code on a MacOS with Mono 2.0 and tested with a MS .NET on windows too.

no slides nor mind map this time, i’ll be using FitNesse pages themselves to show how FitNesse works. the code is here.

hope the README file is enough to start working with the examples. on MacOS i had troubles with the boundled NAnt that comes with Mono, so i had to manually add this to my .profile file, as described here:

export PKG_CONFIG_PATH=/Library/Frameworks/Mono.framework/Versions/Current/lib/pkgconfig

thanx to all the Alt.NET guys for the opportunity, and to Luca first, who was my proxy to the community.

happy customer-testing!

One year of presentations

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!