Domain-Driven Design

It's been a while since a colleague (thanks, Nolan) recommended this book, but I finally read it: Domain-Driven Design by Eric Evans. The author talks about a kind of code debt I'd intuited a long time ago, but could never describe in words--a semantical mismatch between the mental model used to explain the code and the language used by domain experts. This book is important because with an alignment between the code and the domain, we can automate at higher and higher levels of abstraction, and therefore reap the benefits of rapidly increasing productivity. This is the greatest value of custom software--the domain-specific objects that reflect a team's understanding.
In Philadelphia, our team focused our code by naming projects, classes, and methods in ways that business stakeholders would recognize. This made it so we shared a ubiquitous language, as Evans calls it, a clear set of names that make sense to both developers and stakeholders. Something we didn't do enough of, though, is refactoring as the terminology evolved. We did practice merciless refactoring, but it was driven primarily by technical needs. Evans also mentions that the natural language of domain experts will be imprecise and self-contradictory, so it's important to be able to create, together, a new language that is unambiguous. Humans are especially adept at creating language, and the process of using our new shared vocabulary will propel us to simplification--we naturally find easier ways to say things. By implementing these verbal shortcuts in the code, it is simplified as well. The resulting deep model will constantly evolve as our understanding of the domain improves, and our communication about the domain will become more and more precise. In fact, the communication can become so precise that Evans reports an end of the "mystifyingly unexpected requirement changes". The new language used to describe the domain model can be so powerful that it's a selling point for marketing purposes, it's a market differentiator!

The following are points I underlined in the book, but may not make much sense to anyone else:

When we're working on a domain model, name things to reflect intention, rather than implementation. Evans also likes "closure of operations" because they perform operations that bring along no other dependencies (closure means input/output are of the same type).
Evans presents many ways to simplify the domain model, for example:

• by constraining many-to-many associations with a clarifying attribute
• minimizing the number of associations
• making associations uni-directional

If the code is in need of significant refactoring, prioritize by clarifying the core domain first.
He also discusses entity objects, value objects, and services, the last should optimally be an operation that does not fit in either an entity or object, it takes some entity or object as a parameter, and it's stateless.
The Repository pattern is a way to keep caching/data store and retrieval from polluting the domain model. Essentially, the repository objects will act as if they are a permanent in-memory collection of persist-able objects, with even some helper methods for quick retrieval of often-run queries. Repositories are made to retrieve existing objects, while factories create new.

Agile Besançon

So tonight we held the first meeting of what I’m calling Agile Besançon… it builds upon some organizing work that Ludovic, Olivier, and Regis have done in the past—going back as far as the coding parties that Olivier held at his house.  Tonight’s meeting was held in a conference room at Temis Innovation, the incubator for the startup I work for, Smartesting.

Ludovic and I facilitated a discussion on Managing Multiple Projects at Once. Conventional Agile wisdom recommends against multi-tasking, and against running multiple projects with the same team, because task-switching incurs a heavy performance cost.  Still, some teams cannot get their management or their customers to focus—so how can they cope?

We started the meeting with a brief check-in, describing how we hope to have monthly meetings where we can play, practice, and discuss topics/skills that we don’t normally address during our work day.  Then we showed how we planned to use the time for the evening—check-in until 7:15pm, game until 8:15pm, and retrospective until 8:30.  We all introduced ourselves with name, job title, and company affiliation, 11 in total, 3 companies represented. 

Ludovic and I had invented a group exercise to help people warm up to the ideas we’d be presenting—the object of the game was to use an assembly-line of workers to build paper airplanes—15 copies each of 2 different models.  We started with a 5-minute prototype phase—and the Acceptance Test for completion was that the plane had to be able to fly across the room.  After a brief pause, we gave each team (of 4) 5 minutes to build their planes—but they were forced into a Taylorist production model—one person rips out a page from an old magazine, next person puts one fold into the sheet, next two people are plane builders—of the kind of plane they had prototyped.  In 5 minutes each team had built about 6 planes—and we then talked for 5 or 10 minutes about what we noticed.  Then each team had a 5-minute huddle on how to improve the assembly line, followed by another 5 minutes of production.  This time each team produced 16 planes—but one team focused on model A, while the other team built both types.  Only one team noticed a hidden requirement written on the whiteboard—that the customers only pay for completed batches of 15 planes.  Afterwards, we talked about the strategies the teams used to speed up (moving more people to the plane-building role, thanks to Theory of Constraints), and we talked about what might help them reach the goal of selling both plane types.  Someone suggested re-negotiating the batch size requirement—and we said that is an excellent way to deal with multiple projects—that as soon as we can get to small releases (minimally marketable features), it’s not as penalizing to switch off to another project—but to switch before releasing means shelving the unfinished investment and therefore indicates waste.  We followed this discussion with a perfection game on the game itself:

The notes, translated from French, indicate that we should keep the:

• short iterations
• brief reflection after each iteration
• simple materials
• prototype phase

For next time we might consider changing:

• construction targets—different objects, like a boat and plane, or simple folds instead of more precise objects
• don’t run an acceptance test for everything?
• the number of projects (have more than 2), and find a way to get people more actively involved in decision-making/collaborating
• making different objects worth different prices, maybe depending on the construction cost

Points of confusion, open questions:

• what was the overall goal?
• how can we help people be more collaboratively involved?
• deliver airplanes?

We ended the night with a quick Blond-ROTI chart (Return-On-Investment):

   

Translated, on a scale of 1-10, people rated the following:

• Worth it to come to the meeting tonight:  8
• I learned something: 5-8
• I will change something tomorrow: 1-7
• I’m ready to lead a discussion for the next Agile Besak: 2s and 8s
• I’ve encountered this problem: 1s and 9s
• Would it be interesting to have more of us: 8-10
• I will invite someone the next time: 9-10
• I’m ready to come the next time: 10
• There should have been more experience reports [tonight]: 10

Agile Developer Skills Workshop--Day Three

Today is the culmination of the three-day workshop... I think the team has really gelled with a common purpose and shared values. I had to leave early, so will only report on the morning--but stay tuned because soon we'll have something sufficiently well polished that we don't have to hide our candle under a basket.

So, with the caveat that the group may quickly change direction (we're all agile, right?), I'm happy to report on where I think we're going. We'll be creating the Agile Skills Project, an ongoing, open, and not-for-profit entity that will do the following. But first--who is the "we" that follows? Assuming that you're at an experienced practitioner level, it probably includes you:

• create an "agile skills inventory"--a list of skills that are important to being a good agile team member (note, this is not just for coders), a definition of those skills, and even links to existing learning materials (books, web sites, courses, classes) that may help one acquire these skills. These skills will be mapped to the Seven Pillars, and specific ones will be selected as fundamentals that every well-rounded agilist should know


• provide a way for individuals/teams/orgs to self assess against the inventory--this can be an index into where they should focus self improvement efforts, or what kind of help to seek, paid or unpaid.


• recognize progression along the agile skills inventory--the intent here is to celebrate the successes we make in our life-long learning; the risk would be that people could misconstrue this as an endorsement of a particular competency, which it is not. We see several levels of progression through a skill: exposure/awareness, attempted, successful execution, refined execution, advanced the state-of-the-art. From the "successful execution" level and up, there would be third party verification that the skill was indeed performed correctly.


• characterize learning materials--we'll be able to map existing courses, certifications, conference sessions, books, etc. back to how much they cover the agile skills inventory. This will give a nice "nutritional content" to these learning materials, and help people see the objective value these materials provide


• collect experience narratives--at some point, all this work should tie back to the correlation between delivery and skills. This will provide data that correlates successes and failures to how we do the work.


• review experience narratives--With experience narratives, we'll be learning from practitioners in the field, and be able to improve the Agile Sklls Inventory accordingly. As a nice byproduct of experience narratives, we'll have a paper trail of what progress individuals have made in their learning journey.
  

Agile Developer Skills Workshop--Day Two

So imagine an organization, run by the agile community (or a large subset of it--at least the people that have shown a trustworthy commitment), that is in charge of defining the set of skills we find useful in being a member of an Agile Team. This group would be involved in:
-defining an Agile Skills Inventory (e.g., Active Listening, Story Splitting, Test-driven development)
- providing a repository for reference courses
- defining self/peer assessments
- defining a quest ecosystem
- experience reports
- characterization of external courses (for a fee?)
- rating of trainers for a particular course

Well, this is what we're trying to imagine, and here's how we attacked it today--in several sessions. The group asked me to help facilitate (thanks, Pat, it was a great honor! though I'm not sure if I did in fact keep us on task):



We pondered what value this system would produce, so we talked a bit about supply and demand:




Then we talked about the idea of "a quest ecosystem", or points, or merit badges, or achievements, and ultimately thought it could be called tokens. Basically, we'd like to acknowledge the work people do to improve their developer skills:




Then we tried to clarify what this Agile Skills Project would be all about:




Essentially, what we see right now is that the community would own and maintain the ever-evolving definition of agility, then certify training organizations/courses/study material against the standard. To help developers, these 'certifications' would characterize the courses; alternative free methods would also get characterized as well--so then it's up to the developer to take a course or teach oneself.

To further help the community, we'd have a 'token' system, by which team members could go on learning 'quests' or exercises, which would be recorded in a web site as an experience report. This report would be rated by peers and generate points for both the reviewer and reporter. These points would not be fungible, would have no external worth, but could be used to help people categorize their own strengths and weaknesses, to prioritize further learning quests.

One of our group members took some of the initial 7 pillars work (technical excellence, collaboration, product understanding, supportive culture, business value, confidence, continuous self improvement) and made a wordle picture:

Agile Developer Skills Workshop--Day One

Today a group of interested and interesting folk (I'll get a list of the 14 attendees soon) met in Ann Arbor to discuss the Agile Developer Skills idea. We started with a quick outline that I hoped would move us from a group to a team--a list of what motivated us to show up at the meeting, a reality check on what our goals were and if our sphere of influence was sufficient to make it happen, a list of customers, and then a discussion of a business model that could sustain this system.











We soon moved into a mindmap of our various motivations:

























Then we brainstormed on a list of personas that may be our "customers" or stakeholders.

Then we discussed possible goals / to-do items / outcomes of this workshop.

The next steps are to filter the list of proposed outcomes and to review, in detail, potential "generally accepted curricula" that could be used in various courses.

Agile Developer Skills Workshop--Homework

In the wake of announcements from the Scrum Alliance and Microsoft on a "Certified Scrum Developer" program, that would cost around $4-5k per developer, Ron Jeffries and Chet Hendrickson are hosting a discussion on how we, as a community, can support skills development for developers/agile team members. In preparation, I hosted an open space discussion on the topic at Agile Tour Besançon, and a parallel session ran in Agile Tour Philadelphia. The community has long resisted any developer certifications, for many reasons:

• existing schemes don't seem to measure the most important skills
• certificate possession doesn't seem to correlate with skill
• certification has been expensive
• etc.

When I spoke with other developers, the following topics came up:

• how is any test/class going to show if I'm good at my job?
• who is going to pay for the test/class?
• why should the Scrum Alliance or Microsoft or WAQB or any company be able to define agility?
• what happens if people get the cert and I don't?
• etc.

I also had a nice conversation with Laurent Bossavit about the topic. He suggested that at the workshop we ban the word certification--that way we'd have to reveal the motivations for wanting the program at all. He feels like certifications are a replacement for a system of trust--but once money gets thrown in, we need a way to justify the system--a way to explain what people are paying for. One motivation for creating a system would be to show who in the community is worthy of emulation... to show what behaviors are valuable, what practices are effective. In any case, this system should be community owned, democratic, and should value/reward life-long learning, while still fostering innovation towards better ways of developing software.

competing with free products

TestObsessed just Tweeted about how to compete with free products: http://www.businessinsider.com/how-to-compete-with-free-products-2009-9

Short version: beat free with ad-sponsored.