Claudio Perrone’s Monologues

As software developers, we love to delve deep into technical matters and write code that delivers value. It’s not a big secret, however, that many problems in software originate with people and not technology. In my experience, the biggest issues arise mostly due to corporate politics, lack of shared values, poor attitude, inadequate communication skills, and, lastly, faulty perceptions.

Ultimately, the way we see the world affects the way we logically reason about it.

Imagine a team of developers and a customer discussing what to do, using agile stories as their starting point. I use the term “customer” to describe the role of the domain expert who prioritizes stories and can clarify what problems a new system is supposed to resolve. Ideally, the customer knows precisely what to program and the team knows exactly how. More realistically, however, requirements evolve both as the team better appreciates the nuances of the business domain and the customer realizes the possibilities and constraints.

But what would happen if both the customer and the development team had a truly open mind and a willingness to be wrong? What solutions would they come up with if they all had a creative attitude and used a language designed to help them restructure their thoughts? I’m suggesting a catalog of practical refactorings and patterns that would add some rigor to anyone’s thinking process!

The great creativity masters can teach us very relevant lessons in this context. Edward De Bono’s “Serious Creativity” book, for example, contains lots of insights and sets the foundation of the first thinking pattern I’m going to introduce:

Extract Concept

Motivation

Extract Concept is one of the most regular techniques I use to deliberately increase my ability to generate alternatives. In fact, it is so basic that, at first glance, it might even seem too obvious. But don’t be fooled. Its mechanism taps into our human talents of abstract thinking, and it is a good step towards sharpening our creativity skills in a disciplined way.

Perhaps the most important benefit is that it forces me to look for alternatives even when I’m fairly confident that the first idea I have is good enough: I’d ask questions such as “this is a way of doing what?” and “how else can this be achieved?” This attitude is particularly important as I know that if I blindly trust my first instincts I may miss tremendous opportunities.

Alternatives must have a reference point: I’d ask “alternatives with reference to what?” A new concept becomes a fresh reference point that can somewhat change my perspective and lead to further ideas.

Mechanics

1. Define the objective. It might be general or specific, but make sure that you are very clear about what you are focusing on!
2. Identify one or more ideas relevant to such objective.
3. For each of those ideas, extract a broader concept by asking: “this is a way of doing what?“
4. See how each concept can trigger further alternatives by asking: “how else can this be achieved?“
5. If applicable, find further alternatives by extracting an even broader concept (a direction) from one or more existing concepts.

Example

• I start defining the problem: “Provide useful help on our website”.
• I quickly identify as many relevant ideas as I can. In this case is pretty easy to get a good few of those, but let’s pick 2 of them for simplicity sake:
  • Add “?” icon beside potentially confusing fields to open a popup dialog
  • Provide Email address

• For each of those ideas, I extract one or more concepts:
  • Using the “?” icon, is a way of answering questions on the same page they arise
  • An email could be seen as a form of human interaction when visitors can’t find the help they need.

• Using each concept, I can now identify more alternatives:
  • The concept “Answer questions on the same page they arise” leads me to the following ideas:
    • Use the “?” icon to inline-expand helpful hints
    • Add permanent “why?” sections beside each form section
    • Add (light-grey) instructive text directly inside each field (that disappears when the visitor clicks on a field)
    • Add help search section within page
    • Add inline validation (to show error messages within the form before the visitor has the opportunity to click the button that submits the form data
    • …
  • The concept “human interaction” helps me finding further alternatives:
    • Phone us (visitor calls us)
    • We phone you (visitor gives us his/her number, we call)
    • Forums (let visitors help themselves)
    • Chat
    • …

Writing about muffin morning was fun, perhaps because our current sessions are very enjoyable.

As I will gain more understanding of the forces at work and the wide implications of this simple practice, I will update the pattern with the new findings.

By the way, if you are implementing it (or considering putting it into practice) within your team please share your thoughts!

For my future reference, I want to add a few points that I haven’t covered in my previous post, mainly because a pattern should be based on observations rather than speculations.

So what did I leave out? Many things for sure, but for now I only have this list:

• Environmental factors conducive to this type of activity
• Relations/interactions with other practices, for example daily stand-up meetings
• Higher management perception/acceptance
• Pressure/deadline handling
• Basic financial support and equipment
• Team size/composition/roles and correlation with volunteer availability
• Finding engaging topics on a regular basis (experiences on the job, technology/product/process, dept vs. breath of coverage)
• Format (lecture, open discussion, study group, etc)
• Time management (preparation phase, delay, overtime, rescheduling, recurrence)
• Session/topic follow-ups
• If/why/how-to involve other teams

In all the cases I just mentioned, I either don’t have the problem or I don’t have conclusive data, solutions or suggestions.
At least, not yet :-).

At the software architecture workshop held in Cortina last February, JC Oberholzer mentioned that he has been doing a special meeting on a weekly basis for the last three years, with the aim of sharing technical information and improve the morale of his team.

In the past, I thought several times about doing something similar but I was never quite sure it could work out in a sustainable way; JC’s example, however, inspired me to try it here at InnerWorkings and, after successfully testing it for almost three months, I can certainly announce that not only it works for us, but it’s becoming part of our DNA!

Would you like some details?

Ladies and Gentlemen let me introduce you a half-baked (bun…oops…pun intended…ok stop!) pattern that you will never forget:

Muffin Morning

Software developers mature distinct experiences and learn technologies and techniques that can be relevant to others in their team.

How can I share technical information across a team/organization and encourage a healthy self-learning culture?

The most effective developers generally invest a significant amount of their own time researching new technologies, seeking optimal solutions to problems and continuously improving their skills; this is hardly surprising given the rapid transformations that the software industry imposes.

What is needed is a way to encourage team members to share technical information with others.

Volunteer to illustrate and debate a technical topic relevant to the team on a regular basis. Encourage others to do the same by keeping things simple and very informal. Meet for an hour every Friday morning without exceptions, and provide muffins, doughnuts, coffee, etc.

The most important thing to keep in mind with muffin morning is that if presentations become too formal, too long or elaborate, few will be able to contribute as it will require too much preparation; a team deadline could easily break the regularity of the event and muffin morning would become nothing more than a failed experiment.
As a consequence, PowerPoint slides should be absolutely banned and the urge to show live code examples on a projector carefully considered.
I personally find that the most successful presentations are the ones that use a whiteboard only, as they encourage a greater dialog and instigate curiosity to find out more about a particular topic.

One of the biggest attractions of muffin morning is its capability to involve several team members in a communication and self-development exercise.

Independently from their presentation skills, volunteers are almost invariably cheered and supported by the rest of the team since they earn the respect of their peers for their courage and effort.

While volunteers have usually enough interest and understanding of a topic to be able to illustrate it to their peers, it is not expected for them to be experts on the subject. Indeed, often some other team mate may happen to have more experience or knowledge about the subject and consequently play a supporting role for the event.

Last week Eamon O’Tuathail of Clipcode released a Domain Specific Language (DSL) for some of the Gang of Four design patterns using theMicrosoft DSL Tools for Visual Studio 2005.

It is indeed a very remarkable proof of concept and although the implementation is still pretty rough, it represents a valuable model for discussion and learning.

Eamon is very active (particularly) within the Irish community and he is a regular speaker at the Irish .Net Developer Alliance (INDA) events where I often see him.
I briefly talked to him last night as we both were present at the excellent Roy Osherove’s talk on agile development and unit testing best practices.
Eamon told me that he only spent a couple of days developing it; this is something I consider rather impressive given the premature stage of the supporting tools currently available (I bet that his superb documentation took him more time to develop ;-)).

The DSL designer currently allows setup and code generation for five patterns:

• Abstract Factory
• Builder
• Factory Method
• Prototype
• Singleton

Overall, I liked the organization of the code templates in the debug solution, as they are neatly located in a common folder and are referenced only through the ClipcodeEngineTransform.ReportTemplate file which acts as a template controller for all the instantiated designers.

Besides some understandable limitations of both the language and the underlying platform (i.e. the DSL Tools) that will be undoubtedly addressed in future releases, my main interest (and point of concern) lies in the level of abstraction of the model.

Using the language to generate code that realizes a pattern is pretty straightforward as the designer diligently constrains allowable classes and connections.
However, my worry is that, in order to realize a pattern, you need to select every single participant (class/object) from the toolbox and manually connect it to the permitted collaborator(s). As a consequence, you end up creating a diagram that matches quite closely the classic UML representation of each pattern. But do we really need to visualize the structure of a pattern?

As my exploration of the Domain-Specific Modeling (DSM) world progresses, I’m more and more obsessed by the idea that if we want to create the biggest ROI, it is essential to push our models towards a level of abstraction that is significantly higher than the level at which code statements and classes are written.
In other words, a one-to-one mapping between a class created in a diagram and a class generated in code does not generally save enough time and I would dare to consider it an anti-pattern.

A symptom is that the toolbox is generally filled with lots of different elements even if the main concepts (in this case the GoF patterns) are more coarse grained.

So here is a challenge that anyone interested can take. In order to realize an abstract factory, I should need to drag only one class on the designer (e.g. AbstractClassRealization) and setup its participants (AbstractFactory, ConcreteFactory, AbstractProduct, ConcreteProduct) using compartments only. Is it possible? I guess so. I will try soon anyways.

By the way, if you think about it, a GoF pattern is still at a pretty low level of abstraction. In fact, it is the very essence of an OO pattern to address recurring cross-domain concerns. So a “real” DSL may still be built on top of it and possibly provide an even higher return of investment for your organization.