We'll see | Matt Zimmerman

This warrants some explanation. If you just want to know what to do instead, skip to the end.

For over three years now, Ubuntu has been using Launchpad to track bugs. This has been an overwhelming success in terms of the number of bug reports filed, so much so that we have trouble keeping up with them.

Ubuntu, like Debian, carries a huge variety of software, and we accept bug reports for all of it. This means that all of the problems in thousands of independently produced components, as well as all of the secondary issues which arise from integrating them together, are all legitimate Ubuntu bug reports. Casual searching hints that for a given problem with a free software program today, there is likely a bug report in Launchpad about it.

What do we gain by collecting all of this information in one place? We get the big picture. We can make connections between seemingly unrelated bugs in multiple programs which point to a common cause. We can quickly and easily reclassify bug reports which are filed in the wrong place. We can provide a feed of all the data, and access through a single API, so that it can be analyzed by anyone. It gives us a coherent view of the bug data for all of the projects we depend on.

So, having all of these bug reports is useful. How do we make it manageable? We never expect to have zero open bugs, but we do expect to ship products that meet people’s needs, and that means that the worst bugs get fixed within the time available in our release cycle. We’re limited by how quickly our triagers can read and evaluate each report, and how quickly a developer can analyze and fix the problem.

The good news is, you can help accelerate both groups’ work with one simple step: report bugs using ubuntu-bug rather than going directly to Launchpad.

This automatically includes as much information as we can collect about your problem, without any additional work on your part. It’s easy!

$ ubuntu-bug network-manager      # report a bug on Network Manager
$ ubuntu-bug linux                # report a bug on the Linux kernel

The man page for ubuntu-bug contains more examples.

Of course, there are some circumstances where this is not possible, and you can still file bugs the old fashioned way if necessary. If you do, please remember to include details such as which version of Ubuntu you’re using, which package the problem is in, which version of the package is installed, and so on. Read the official instructions for reporting bugs for more information.

This weekend, I took my longest train journey in recent memory. It was only a matter of hours, but after so much air travel over the past few years, it was a welcome change of pace.

I could freely cross and uncross my legs. Power and wifi were widely available. All of this in standard class!

Where do I sign up for more?

The 24th of March was Ada Lovelace day. I’m not sure why it was so designated, as Wikipedia claims Ada Lovelace was born on 10 December and died on 27 November. Regardless, many people celebrated it by writing about women in technology. This seems like a good idea on any day of the year, which is why I don’t feel left out in joining the crowd a day late.

The woman who most influenced my own journey in technology was my mother, Margie D’Valle. When I was born, she was working in a technical role for the US government. I believe she was called a “Computer Operator” at the time, which sounds a bit funny now that computing devices are so pervasive. She worked as a programmer, and later as a manager of programming teams. In addition to raising me and my sister as a single parent, she encouraged and enabled us from a young age to become “computer literate”, another term which soon sounded archaic.

Her programming work itself was largely invisible to me, being a proprietary system which was only used within a single organization, and I didn’t learn much about mainframe technology until much later. She sometimes told stories of programming, or debugging, or working late to get a release out, which have since been shared by many people, including myself. At the time, they had a certain element of fantasy, as if they existed in another world.

I think it’s wonderful that so many women can now be recognized for contributing to open source, where they can inspire millions of people around the world, for generations to come. I expect, however, that their influence has been greatest on the people they know best, and so it was for Margie. She helped me see how computer technology would change the world, and helped me to be a part of it.

I’m not sure what experiences she may have had with discrimination against women in her workplace, though the events of Ada Lovelace Day have made me curious to ask her. She has since retired from her job, but I’m sure that her code is still running, tirelessly performing the invisible but necessary work of keeping important government services alive. Such systems evolve slowly, and it may survive for many years to come.

Thanks, Mom!

We are all called upon to act as leaders in some stage or capacity of our lives. A healthy, developing person is constantly growing and changing, and exercises personal leadership to continually assess and adjust their direction. Leaders in organizations apply the same pattern to the teams and other systems around them. They recognize inconsistencies between the way things work today in the organization, and the present and future challenges of its environment.

Having identified such an opportunity for improvement, we are faced with a question: where to begin? How can the system evolve from this form to that? How can I facilitate that change? The most effective leaders I’ve seen don’t look very far for the answer. They start by changing themselves, and thereby their own behavior toward others. They do this for a number of good reasons.

First, we have greater influence over ourselves than our environment, because we can understand our internal world more readily than anyone else’s. We therefore have a better chance of success in our efforts. Building on that foundation, we will begin to affect others in small ways, often without even knowing.

Furthermore, meaningful and lasting change is usually inspired rather than directed. Consider the traits you value in yourself, and the people who have helped you to develop them. Do you more strongly identify with the paternalistic figure who says “you must be…” or the role model who showed you a different way by silent example?

We are highly adapted to recognizing problems in our environment, and socially conditioned to try to correct them through action. This emotional impulse is a strong one: I see something I don’t like, and I want to stop it or change it. This approach works well for inanimate objects, but not so well with people. We resent others for trying to change us, because we value ourselves as we are. Who are they to tell us how to be, when they too are imperfect?

The catch, of course, is that changing ourselves is hard. It is nearly hopeless without understanding what we are, and perhaps some of how we got that way. It is easy to become caught up in other people’s apparent problems, thinking that you can fix them, or even know what they are. If I stop and think, though, there is generally always something I can change within myself which contribute to solving the problem. Often, this means working at a deeper level, setting aside my superficial view of the situation and understanding what is behind it. What might they be feeling which inspires their behavior, and how am I affecting them? How can I change in a way which will give them the confidence and perspective to see the problem more clearly and act for themselves?

I probably heard this principle, in some form, a thousand times before I managed to internalize it, and I still forget, sometimes when I need it most. I hope that writing this will help to remind me of it in my life. It is simple enough, but requires great discipline and practice to apply consistently.

From time to time, I see someone remark that Ubuntu uses packages from Debian unstable, and that they don’t think this is a very good idea. I would like to explain why we do this and how it works, and hope that this will enable a less one-sided view of the subject.

Debian is well known and regarded as a product, the Debian system itself. In addition to this end product, the Debian community produces a variety of useful by-products. One of the most celebrated is Debian “unstable”, which despite its unglamorous name is an incredible achievement. It represents the collective work of a vast number of developers, who package and maintain essentially all of the free software available.

Put simply, Debian unstable provides immediate access to anything you could want from the free software world. It’s all there, updated daily with the latest and greatest releases. As if that weren’t great enough, the components are continuously integrated, so that problems become evident right away and can be fixed quickly.

Debian doesn’t “release” unstable directly; it’s an intermediate stage in their process. The Debian release team selects components which they believe are ready to release, and place them in “testing”, which is the next stage in the process. However, many people, developers especially, use unstable as their primary operating environment. They drink from the firehose of free software, delivered daily by Debian.

Ubuntu was created in a similar spirit, but with significantly different goals. We wanted to release a complete product much more frequently and regularly. We wanted to focus on desktop users, and provide a system which met their specific needs, even if this meant serving some other needs less well. In this way, we created a complement to Debian, as many others had done before us.

What we did differently was to choose unstable as the basis for this work. There are many other distributions based on Debian, but at the time, they were mostly derived from a particular release. Debian would make a release, then someone else would take this and produce a customized version of it. The problem was that these customized versions would become outdated as Debian continued to develop. Bringing them up to date with Debian’s latest work required a lot of effort, particularly as Debian’s releases were sometimes years apart with massive changes between them.

Basing Ubuntu on Debian unstable meant keeping up. We would continually merge in the latest code from Debian, keeping Ubuntu closely in sync. While this was sure to be a lot of work, it provided us with access to all of the pre-packaged software we would need to produce Ubuntu, freshly delivered every day. Instead of duplicating this work, we could build on it.

We would, of course, need to do our own release management, and make decisions about what was ready to ship, just as Debian’s release team did. We couldn’t reuse their work, because we needed to make different decisions in order to suit our distinct release cycle and provide the desktop experience we wanted.

These decisions reflected some of the key advantages of free software. We could get the benefits of a custom solution without having to reinvent every wheel. We could focus on the pieces which mattered most to us, and use stock components everywhere else. We showed that this applied to open processes as well as open source code.

This is why, and how, Ubuntu was based on Debian unstable. It was, quite simply, the best tool for the job, and still is today.

…you walk down the aisle, find your row and seat, and find that…

1. It’s in the center of a row of five
2. The plane is completely full
3. There is no seat cushion!

This seat has no cushion

For the last full day of the workshop, we took part in a delegation simulation. The class was divided into two groups, each of which developed a problem for the other to solve within a time limit.  Both halves of this exercise were equally interesting: working as a team to decide on and develop a problem, and then solving a problem designed by another such team.

In creating a problem, we chose a facilitator and followed a set-based design process. We generated ideas through brainstorming, clustered them, eliminated most of them by agreeing on some guidelines, prototyped the remaining two, and voted to decide between them. This process was not entirely smooth. While we successfully applied several lessons learned earlier in the week, there was some conflict in the group which proved difficult to address while still completing the task in the available time. In one case, two members of the group did not seem to agree with the process we were following, and refused to take part. In another, one person’s work was erased by another without their agreement. Even in a classroom environment, where the stakes were low, these were tense situations and required careful attention to maintain the effectiveness of the group.

In the end, both groups produced problems which were loosely specified, and allowed for a great deal of creativity in the solution. This led to a valuable insight into effective delegation. Jerry defines problem solving leadership as the ability to enhance the environment so that everyone is empowered to contribute creatively to solving the problem. By providing a minimal specification with only essential parameters, members of the group were both empowered and inspired to contribute individually in unique ways. The motivational effect was palpable.

Photo credit: Rickard Johansson

Both problems could easily have been solved in a trivial fashion by one person, but instead, the teams seized the opportunity to engage their creativity. In observing the other group solving my group’s problem, I could watch how everyone in the group found a way to contribute according to their abilities, without conflict or confusion. The end result was of much better quality than we anticipated.

The problem specification had created an environment in which the team could flourish, and this enabled both efficient organization and high motivation. Two of my classmates, Henrik Kniberg and David Barnholdt, have since experimented with this idea in their own teaching. They designed exercises which compare the behavior of problem solving teams in response to problem definitions with different levels of detail. They’ve shared the results on their blogs, which are worth reading.

This type of creative delegation is not without its pitfalls, of course. I could easily imagine getting drawn into the game Jerry called “bring me a rock”: ask someone to bring you a rock from the nearby stream; when they do, answer “not that rock”, and ask for another; if they ask which rock you want, answer “I’ll know it when I see it”.

This game mirrors many failed attempts at delegation. Creative problem solving only works if you are prepared to accept something different from what you might have expected. This means letting go of your own approach to solving the problem, and letting them solve it their way. Jerry described this with a great analogy to a monkey trap, where a monkey’s fist is caught in a hole because it won’t let go of the bait. People can be trapped the same way by an unwillingness to let go of an idea.

This doesn’t mean that the problem should be underspecified. It should be constrained to the bare essentials, and specify results rather than methods. As Antoine de Saint Exupéry said, “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

Another idea which resonated with me was communication through “I” statements rather than “it” statements. For example, “I’m frustrated” rather than “it’s frustrating”. This more accurately relates the feelings of the speaker, and helps promote a connection with the audience. Many “it” statements can be transformed into “I” statements in a straightforward way.

Teams get better at adapting to change through experience coping with it together. One of Jerry’s suggestions for team formation was to give the team a problem to solve which is not too easy, but not too hard. This allows the group to “organize through success”. Some of the participants felt that the problems were too easy, and therefore not interesting, but I certainly learned a great deal from them.

We spent the entire fourth day processing the previous day’s simulation.  There were many valuable discussions and insights, of which these are only a few. Several members of the class had volunteered to act as observers, rather than participate in the simulation, and they presented their observations to the others.

When discussing their choice of a leader, the group was tense and talked little, until the candidates left the room.  It’s difficult to openly debate the merits of a near-stranger when they’re standing next to you.  I would be interested to hear from other participants about what this part of the process was like, since I was outside of the room.  With the other candidates, I discussed how the group had responded to us, mused about what the simulation might be like, and possible ways in which the group could be organized.  One of the other candidates had a clear idea of what the structure should be, while I felt strongly that it would be better to learn at least something about how the simulation would work before making that decision.  This illustrated for me a difference in leadership style which I notice in my work as well, and which I suspect is correlated with personality type (though I didn’t check that in this case).

For the second time during the week, I learned something about responding to mistakes (the first time was when I was standing nearest to a house of cards when it collapsed).  This time, when someone inadvertently broke one of the (previously unknown) rules of the simulation, causing the entire team to be penalized, I was the one to deliver the news.  The first question I was asked was: “Who was it?”  Perhaps it was merely a natural request for more information, but it immediately created the impression of blame.  It was irrelevant who had made the mistake; what we needed to do was respond to the problem which was created.  I had seen this pattern many times in my work, but the artificial parameters of the simulation illustrated it beautifully.

There were many opportunities to study systemic problems in the simulation, as information and work product queued up in different ways, and feedback loops evolved to enable the group to respond. .  It was surprisingly challenging to identify the root causes of blockage, despite the simplifications of the simulation, and this is so much more difficult in real-world organizations.  It’s nearly impossible to do it well when one is involved in the work of the moment, as it requires some distance and objectivity.

In one part of the simulation, a small group had organized to work on a particular task.  Without the benefit of prior knowledge about the nature and volume of the work, the space chosen for this was very small, and not at all appropriate either for the materials or the people involved.  This situation persisted for far too long, as no one recognized the situation until much later.  This highlighted for me the importance of regular checkpoints (such as retrospectives), to get perspective on how a team is working and make appropriate changes based on experience.

I expect that every non-trivial organization struggles with communication, and I’m always looking for new ways to improve the flow of information.  I had a striking insight in this area thanks to one of Jerry’s aphorisms: Trust is a substitute for communication.  When you have a strong, trust-based relationship with someone, you don’t require as much communication with them, for two reasons: your communication becomes more efficient (more information in less time), and you don’t require as much information of each other (because you can trust that they are doing the right thing on their own).  Because of this, it’s possible to improve “communication” in an organization by working at the level of emotional relationships rather than information flow.  Based on this, I have reinterpreted some reports of “communication was poor” or “more communication is needed” to mean “the relationship needs work to build trust”.

We also discussed the use of a “zero-level solution” in problem solving.  This is Jerry’s term for establishing a simple, baseline solution to a problem before exploring more complex alternatives.  For example, if the problem is that a program runs more slowly than it should, buying a faster computer might be a zero-level solution.  With that fallback position in mind, a team can then generate and explore other ideas which might be more effective.  I’ve used this technique before, but studying it at PSL gave me a chance to reflect on why it works.  First, it supports incremental development of a solution, with all of the attendant benefits familiar to Agile practitioners.  Second, it provides for fast evaluation of new ideas: if it’s no better than the baseline, throw it out immediately.  Third, and most powerful, is the motivational effect: knowing that there is at least one solution in hand gives the group confidence and safety to explore alternatives.