Analog nostalgia

January 26 2019

I was recently asked by colleagues to help them improve on effectiveness in grasping discussion details and presenting a topic to others. in other words, how the hell does this “paper-stuff” work, when you’re making notes in a meeting or preparing an internal speech to others? so, I’m quickly collecting here a few notes on the topic.

first, making notes:

  • generic meeting: mind maps are a powerful tool to visualise and organise thoughts. just put the main topic as the central node, then let concepts flow as branches in a tree. use colours or sketches to better highlight items and make them easier to remember
  • planning meeting: of course, user stories are the golden tool! just focus the “analog” format, with a bright title, a few notes and eventual questions. they will probably be more like themes or epics, depending on the granularity of the planning horizon (release, iteration), and that’s ok! you’ll have chances to resize them very soon
  • operative meeting: don’t miss any relevant task by filling up a TODO list. my personal format (compared to a more traditional “square with tick” format) consist in a “minus” sign, followed by a quick task note. I then highlight “most important” or “next” tasks with a circle around minus. finally, when task is done, I turn the “minus” into a “plus” sign! whenever a task is no more relevant, I “strike” it with a line

then, presenting thoughts:

  • describe a generic topic: use a mind map to let discussion flow, just paying attention to the order of topics (clockwise, anticlockwise) and the details to be expanded: high-level first, then details (breadth-first) or full details first, one topic at a time (depth-first)
  • describe a plan: again, layout user stories on a table or whiteboard, one at a time, while telling something about the individual story and the overall plan. try different layouts (eg: releases as columns, main flow as row, etc) so that multiple ideas emerge while sharing with others
  • describe a (conceptual) model using “UML as Sketch” notation (eg: domain models, data models or architecture models), by only relying on basic UML elements. at this level, you’ll probably only use boxes (for entities), lines and arrows (for relationships and navigations) and numbers (for cardinalities). evaluate both “static” and “dynamic” models (es: class/object diagrams vs. sequence/communication diagrams) as the most appropriate for the topic and audience

I think that’s enough to start with! would you enjoy playing with paper and pencils? just try it!

Plans for Xmas

December 17 2017

yesterday I heard my little daughter being told by her mom “honey, let’s prepare a list for tomorrow shopping!”. don’t ask me why, but I then started thinking about one of my favourite topic in software development: release planning.

imagine you’re working on an aged software application for your company (eg: an online travel agency), composing products from 3rd parties resellers (eg: flights, train trips, hotel accommodations), adding some extra markup, and selling as bundles (eg: holidays). now imagine that your company aim to add an additional product (eg: additional baggage on flights), available from many of the existing resellers, but not yet part of your offering.

imagine that, from a quick analysis and market research, your company define an initial release around integrating products from a few resellers only (eg: additional baggage from 5 topmost airline companies).

lastly, imagine that your software application has been migrated from a monolith to an (almost) microservices architecture, so that you have dedicate backend components for topics such as resellers (eg: airline/hotels integrations), bundles (eg: markup rules, market-specific composition rules, etc.) and a frontend component for interacting with users.

how would you then approach release planning for the very first project release?

let’s try listing all activities to be performed, such as:

  • collecting products details from resellers (eg: parsing XML or JSON payload in airlines HTTP search API responses)
  • storing new products into catalog database (eg: adding BAGGAGE table vs. adding BAGGAGE type in PRODUCTS table on RDBMS)
  • defining markup rules into bundle database (eg: extending rule engine with new
    BAGGAGE product type)
  • preparing new UI for showing new products details and selecting desired products (eg: simple “baggage-shaped” widget for all available sizes and weights)
  • storing selected products on orders database (eg: full baggage details vs. a reference to available baggages previously collected, stored into ORDER_ITEMS table on RDBMS)
  • purchasing selected product from resellers (eg: adding XML or JSON content to airline HTTP booking API requests)
  • adding purchased products details in confirmation email (eg: simple statement with quick recap on allowed sizes and weights)

that’s a lot of stuff.

there are many risks, probably most related to external service APIs, because they’re not under our control (are those products available to be purchased on test/sandbox environments as well?). but also from a domain perspective, modelling these new products could imply tricky challenges, such as full-details vs. reference storing, reuse existing products and orders details models for sizes/weights as well.

one first approach for planning a release is, well, simply plan those activities in that exact order: start parsing API responses, end with updating confirmation email. in the end, that’s the work to be done, isn’t it?!

let’s call this a “task-oriented” release planning. in fact, that activities smell like programmer tasks: technical, “horizontal” (impacting one layer/component at a time), simple to be performed without additional context (eg: what’s following next). you’ll probably “see” some visible behaviour only at the end of the whole release, or at half of the release: new UI for users and new sentences in confirmation email, which should both be “feature-flagged” off unless the release is complete (but feature-flagged on in QA env or for some test users).

a second approach for planning a release is forgetting about components/layers boundaries and start focusing on users, being that both customers and admins. in other words, focusing on visible behaviour, eventually adding minimal tooling for making it really “visible”. in the example, we could have:

  • dashboard with available products, for admin users (eg: listing baggage that would be presented to real users, for supported companies)
  • new products checkout, for real users
  • selected product purchasing, for real users
  • selected product details in confirmation email

let’s call this a “feature-oriented” release planning. items in this plan are almost functional, “vertical” (impacting many components/layers). risks with this approach is having “long” development activities, before considering “done” a feature. with this approach you’ll learn what incremental development is: adding, one piece at a time.

as a note, I’m referring to the term “feature” as nowadays presented in SCRUM-like release planning: something understandable by C-level executives. I don’t really like the term, I’m used to call them themes (or epics, with no particular distinction even if one exists, by the book). anyway, let’s stick on this for a moment.

one third approach for planning a release is slicing features, trying to keep them as slim as possible, but still vertical. the very first user story will look like to something like this:

  • focus on the very top reseller only (eg: only one airline company)
  • suppor only one fixed product on that reseller (eg: only 1 extra baggage),
  • enable on a small percent of orders (eg: only flights internal to that company main country, where no currency/units conversion is required)

you’ll then move either to more resellers, more products or more orders, according to your company strategic vision and to feedback collected while developing.

let’s call this a “user-stories-oriented” release planning. you’ll probably explore much of the complexities as early as possible, using simplifications to let you go faster. you’ll surely have then change components/layers many times, as you progress in the development. with this approach you’ll learn what iterative development is: rework, from simpler to more defined.

given this long introduction, and example, my very personal suggestion (biased from an XP style for planning) for doing release planning is starting with features (or themes, as I call them), and then move to user-stories. I know, not much original content here (in fact, I’ve been sharing thoughts like this since many years)! sorry mate :)

anyway, two additional hints:

  • don’t focus on tasks (as in the first approach) in the beginning, but let them flow as you’ll start analysing and estimating user-stories. an high-level technical architecture is enough to start planning a release (and later releases as well)
  • don’t have separate release plans, one for C-level people with features, and one for development people, with user-stories. this would require continuous “mapping” between the two. stick on one shared release plan, share on the company wiki, print it and put on walls, update it often

don’t get me wrong, you’ll probably require an higher-level plan for executives, just don’t call it a release plan. I’ve seen referred to them as initiatives or goals, but have not much experience with.

surprised by such a long post, after almost 4 years and an half? don’t tell me, I’m astonished as well! well, let’s consider this my Xmas gift for you!

..maybe it’s just me speaking at Italian Agile Day 2012!

I’m probably the last person to know about it, because of my anachronistic campaign against social-stuff: I think it’s been on twitter for a long time! anyway videos are available on UniMI video portal, also integrated with slides here.

listening or watching yourself is a tough test, you learn a lot about your presentation skills. I now understand why people commented mine has been a boring session, I can’t blame them.

anyway, that’s exactly the content I wanted to share, whit numbers, plans, sketches and links for further reading. sorry for a 5 minutes black-out, funny enough “on the stage”, but we lost very few sentences. again, thanks to all the people at the conference, see ya next year!

PS: my dear handful of reader, for those of you still puzzled, here‘s the answer!

that’s kind of a ritual for me, collecting cinema tickets during the year, then sharing with you movies I liked the most. this year I’ll be quicker, and list only the top 15. believe me, it’s been extremely difficult for me to decide among almost 60 movies!

again, I’m listing Italian titles and linking to the English pages on IMDB. also, some of them have been published some years ago, but projected in Italy in 2012. so, here it comes…

  • Un sapore di ruggine e ossa, for sure the toughest of them all, be prepared for thrilling opening and a closing scenes. an incredible Marion Cotillard will share rise and fall in the life of a whale instructor
  • Detachment, Adrien Brody as an high-school teacher, telling you how to survive this “marketing holocaust” called modern life
  • Monsieur Lazhar, how 10 years old children react to a violent event occurred in their school, helped by the sweetness of an improvised teacher, running away from war in his motherland
  • Moonrise Kingdom, the sweet and funny “elopment” of a young scout and his beloved, across an island lost in the middle of the Sixties. great cast, nice photography, an incredible sound-track (don’t miss the credits!)
  • Ernest e Celestine, a cartoon scripted by Daniel Pennac. the story of a little mouse and an hungry bear, fighting against their cultures to be accepted as friends. targeting kids, this movie shows adults the consequences of prejudices
  • E ora dove andiamo?, problems of Christians and Muslims living together in a little town in Lebanon. only women would prevent tensions from degenerating into a civil war
  • La guerra è dichiarata, a modern “Juliette” and her beloved “Romeo”, quickly turning from a passionate love story into a drama, facing cancer with their young diseased child. Valérie Donzelli, director and main character, tells her true story
  • Piccole bugie tra amici, you won’t keep from laughing, and from crying, with this incredible comedy-drama about friendship
  • Le nevi del Kilimangiaro, realism, socialism and solidarity, settled in the proletarian Marseille
  • Miracolo a Le Havre, an enchanted story about immigration told from a young African kid’s point of view, helped by a penniless couple struggling to survive
  • Sister, “our family is very weird”, but you’ll have to wait to the end to understand how much it really is
  • Cosa piove dal cielo?, sometimes incredible stories are just “your” story. be prepared to laugh with a sad and unlucky “Chino” traveling across Argentina
  • Tutti i santi giorni, probably the best Italian movie this year. Antonia and Guido, so different from each other, in love, young, without a real job, wishing to have a little baby in a chaotic Rome
  • La collina dei papaveri, brand new movie from Studio Ghibli, charming as usual. such a shame it’s been projected only for one day in Italy!
  • La parte degli angeli, Ken Loach new movie about “second chances”. a politically-correct comedy about ex-prisoners and whiskeys, settled in Scotland

that’s all for this year, hope you’ve found here some interesting movie to watch!

hold on for a few hours more, then hurry up! Italian Agile Day 2012 is coming on November 24th!

I’ll be presenting a session on projects evaluation, aiming to put together my past few years personal experience. this is such a interesting topic for me, combining both organizational and technical skills.

I’ll be sharing with the audience techniques for documenting and reporting software project feasibility: coarse-grained release planning, high-level logical architecture, rough delivery effort estimation, basic domain modelling. whatever simple enough you need to get started with a project kick-off. possibly.

see you in Milan!

Remarkable quotes

May 3 2012

sort of an ipse-dixit saga starting here..

iterations are means, not an end. incremental development clocked by fixed-length iterations sure is a great achievement, when starting from a “big ball of mud”-like environment, where no process is applied at all. coding rhythm like “need this in production by tomorrow, can you do it?” isn’t sustainable, so planning one to three weeks long iterations is the way to go.

then – because there should be a “then” – next step is asking business to figure out where to bring the project to: medium-term to long-term goals, also known as releases. the opposite can’t stand: filling up iterations with something good-enough to keep development team busy. iterations are means – achieving business goals on a regular and reliable basis – not an end.

coolness isn’t cool. developers often tend to be delighted by techy/geeky stuff. “I’m working on this ultra complex semantic search algorithm which is going to improve performance by a 24.7% factor!”. “we just integrated X with Y, in a clustered Z environment, only by configuration files!”. don’t get me wrong, I’m far from demonizing this kind of focus on technological issues.

but – because there should be a “but” – we, as developers, are in charge of much more: helping stakeholders achieving their goals, managing software development projects, planning releases, architecting and designing systems. we’re not just coders, our value isn’t counted by how many lines of code we can manage to write in a single pair of curly braces. coolness – complex problems and technologies on hype as ends in themselves – isn’t cool. delivering successful projects is.

yep, philosophy was my first love..

Coherent, in principle

April 3 2012

intrigued by a recent thread on the Italian Extreme-Programming mailing list (sorry, registered members only), I just remembered I collected thoughts about design principles, that I didn’t shared yet.

basically, I tried to map the “overlapping” between the 5 SOLID principles and the 5 GRASP “primary” principles. in my view, they address four basic topics:

  • flexibility (aka software evolution)
  • encapsulation
  • coupling
  • cohesion

sure, that’s nothing new, and they are all related each other. it’s just a quick reminder: “what’s DIP all about? coupling”, “what about Creator? encapsulation!”.

regarding (functional) cohesion, Larman’s book provides a broader context for “measuring” how much an object is cohesive: number of functional areas, number of responsibilities.

sure, this could sound too “academic”. and in fact I can’t keep from smiling and thinking about Dead Poets Society, quoting the “PIG” graph:

“If the poem’s score for perfection is plotted along the horizontal of a graph, and its importance is plotted on the vertical, then calculating the total area of the poem yields the measure of its greatness.”

anyway, High Cohesion principle suggests designing objects with “few responsibilities, in one single functional area”. SRP goes further, saying an object should have a single responsibility. but this doesn’t mean having “one-(public)-method” objects: High Cohesion clearly doesn’t mandate this, nor SRP.

object services (aka published interface) should be narrowed around its single responsibility. Bob Martin says objects with “one reason to change”. so, having only one public method is an option, but not a requirement, as long as published interface consists of few methods, all belonging to the same functional area, all evolving together.

yep, this is hard to achieve. while “few methods” and “one functional area” are easier metrics, something you could understand looking at the code at any given moment, “evolving together” implies monitoring the future, tracking code changes, like commits in a revision control system. given a class, had all its changes a common reason?

I think I’m watching the Dead Poets Society movie again, tonight!

One step up

February 7 2012

it’s going to take so much longer than I expected for me to achieve a good enough writing about this topic, so I decided to start small, share a few initial thoughts, and collect feedback. abstract: what about design concepts and principles when applied at the system level? I mean, do they still stand? is there anything I can learn from the object level?

I’m playing with architecture these days. yes, playing is the right word. I’m almost in a brain-storming phase, reading books and articles, writing mind maps, and collecting data from current and past projects I’ve been involved with. but the analogy soon came clear: what about good design principles, evaluated as architecture principles?

so, here they come just rough bullet points.

information hiding. don’t let implementation details of a given component pollute the system. should client code be aware of persistence mechanics or sorting algorithms? no, it shouldn’t. this information should be hidden inside the component providing those services. so, at the system level, why do we consider integration databases an option? why don’t we hide implementation details such as relational database systems (DMBS) and query language (SQL dialect)? wouldn’t be better to stick on a shared data format, such as JSON, XML or CSV files?

encapsulation. support cohesion and keep related logic together, near data logic works on. don’t ask for values, but tell behavior to be executed. sure, this is strongly related to information hiding. but, what about system design? what about telling a system to perform a given task, instead of asking for data? public APIs and application databases are recipes you can select from your architecture cookbook.

ports and adapters. achieve an isolation level from external dependencies in application code: publish a clear service interface (port, facade) in the application, and provide an implementation (adapter) to a specific external service or toolkit. this is also known as hexagonal architecture. well, when it’s time to design system dependencies, what about putting an extra layer of abstraction, protecting your system from external systems implementation details? this idea is what Pryce and Freeman call simplicators. this video by Pryce explains the idea further, presenting a system where all external systems are accessed through an intermediate HTTP facade, which completely hides those protocols details and pitfalls.

to recap:

  • share database among multiple applications: don’t! consider databases as object internal state, which you’d probably not expose publicly. would you?
  • export data from application databases for reporting, calculations, and so on: don’t! consider those exported data as object getters, which you’d probably not publish as part of object interface. would you?
  • provide connectors to external systems and toolkits in application: to be fair, not so bad. but consider encapsulating them in one intermediate system

does it sound good to you?
to be continued..

One year worth of movies

December 30 2011

this year is getting close to an end, and so it’s time for me to share the results of a very personal experiment I did. I collected almost all the tickets of movies I watched at the cinema during 2011, and they are a lot! yep, going downtown with friends and share a nice movie with them is something I like a lot. sometimes there was a “too complicated” movie to be watched, so the crew was really small!

anyway, it’s time to share my suggestion with you. I’m listing movies with their Italian title, but linking to the English pages on IMDB. also, I’m referring to movies projected in Italy in 2011, even if many of them have been published some years ago.

here it comes the podium.

First place
these are the winners, no doubt.

  • American Life, the great adventure of a young couple, so in love not to be pushed down by life. maybe it’s just because I’m 30…
  • Hereafter, three stories about life after death, smoothly twisting together. I was initially skeptical because of the topic, nevertheless highly recommended
  • La donna che canta, a personal tale quickly turning into the history of Lebanon. you will understand why “one plus one equals one”
  • Angele e Tony, a romantic guy meets a determined woman willing to get married, in order for her to leave the penitentiary. but it soon turns into something deeply different
  • Una separazione, an intelligent representation of modern Iran issues, through the storytelling of an average family
  • Tomboy, teens in trouble with their sexual identity. one of the sweetest movies in the list, especially for the little sister Jeanne
  • In un mondo migliore, a cruel Danish movie about malice and human instincts, and their consequences
  • This must be the place, an ex-rockstar getting back in touch with his family, and willing to complete what his dead father started and dedicated his life to. first Italian movie in the list, with an incredible Sean Penn
  • Il ragazzo con la bicicletta, a teen looking for a family, and a woman discovering her parenthood
  • Precious, no matter how much life push you down, you’re still precious. even being an abused, raped and pregnant black teen girl, living in New York suburbs
  • Biutiful, an incredible Barcelona watched through the eyes of an outlaw, which is also able to see his death
  • La versione di Barney, a funny story about a man and his troubles with love. a great Dustin Hoffman and his “Mazel tov”!
  • Another year, exactly what the title says. Tom and Gerri, their relationship with others, their willing to keep happines in their daily life

Second place
these are movies I liked, worth watching, but that didn’t leave me something as deep as for those above.

Third place
worth being cited, but I would not probably watch them again: Pina, Kill me please, The tree of life, Faust and Urlo.

Off the podium
I’m almost done. if you didn’t have enough, these are movies I didn’t like so much, but maybe they’re ok for you, worth spending 2 hours on sunday evening: Il debito, Tamara Drewe, Il discorso del re, Amore e altri rimedi, Crazy, stupid love, La vita facile, Ladri di cadaveri, Holy water and La fine è il mio inizio

great, I’m done. hope you enjoyed the report, and that you could find something interesting to watch soon!

Release the dogs

December 17 2011

I’ve been thinking about this post since a few months, and I’ve now got some more data to share about. the title stuck in my mind while listening to “Tomorrow Come Today” Boysetfire’s album, driving back home after an intense day of working with the team.

it all started in a study session on the XP practices, discussing what was stopping us from applying some of them. for example, Small Releases. the immediate objection was “well, we deploy more than once a week!”. in fact, user stories are moved to production as soon as they’re completed, validated and accepted. so, is this a non-sense question?

this week we kicked-off a new project, which is critical, because it aims to improve the company product’s core. the stakeholders asked for a technical solution that could answer the question “is this worth it? does the company receive any benefit from the new business rules”. so, we agreed on an architecture that keeps the two sets of rules in parallel for a short period, and as soon as we collect positive data, we’ll switch the product to the new system.

it took us two days to come with a Release Plan and an Iteration Plan for the first iteration. we collected themes and user stories, discussed a feasible architecture, then set rough estimates. this initial process showed we could answer stakeholders’ question in less than one month. then, it would take us another month to develop enough user stories to switch to the new system. eventually, we could then focus on the less important themes, which we didn’t even analyzed nor estimated, just tracked down on index card.

to recap, we focused on the smallest chunk of stories that could be put into production in order to bring value as a whole, and a release date has been attached to. then we iterated this process. the result is a three-releases plan, which is being adjusted and adapted whenever we found something new about estimates, technical risks, and the domain itself. we also know the first release it’s about two iteration long. then we know what’s going to be developed for the next two weeks, in much more detail, having discussed acceptance criteria and technical alternatives.

back to the initial study session, I think the problem is due to the fact we talk in Italian. the Italian for “release” and “deploy” is exactly the same: “rilascio”. we say “piano di rilascio” for “release plan”, and “rilascio in produzione” for “deploy to production”. combine this whit the continuous delivery practice gaining more and more popularity these days, and maybe the communication problem gets explained. to be fair, the project we referred to, deployed on production frequently, was more in a maintenance than a developing phase. there was no clear reasoning about planning. hence the confusion.

to recap, and to state a take-away message: don’t confuse release planning with production releases, especially if in your native language the two words sounds similar. my suggestion is to mentally translate to “milestones” for release planning, and to “deploy” for production releases. would this help you?