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