Tuesday 13 October 2015

Write The Docs: Judas Priest Ate My Video

Earlier this year I gave a talk at Write The Docs, in Prague. I have written about the content of that talk previously. The good folks of Write The Docs have now published the talk recordings from the event. Mine included.

Once again, my thanks go to the organisers and the attendees of Write The Docs. It's a really fun event with a great mix of different participants. I cannot recommend it enough to people (or companies) that have interest in good tech writing.

Wednesday 30 September 2015

Daily Scrum and the Three Questions of Doom

Oh yes, the Daily Scrum. That stand-up meeting that happens at the beginning of the day. It is a planning meeting. Not a status update. The Scrum Guide, in a rare moment of being prescriptive, even dictates the questions that should be asked in the meeting:

The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, the Development Team members explain:
  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

So why do I call these the "questions of doom"?

Getting Beyond Mechanical Agile

Are the questions, themselves, the problem? Like a lot of things with Scrum, it is not the mechanics you need to look at. It is the surrounding culture you need to pay close attention to. So, by themselves, no, I do not think the questions are problematic. Let's take a look...

What did I do yesterday that helped the Development Team meet the Sprint Goal?

In a meeting about planning for the immediate future, looking back might seem like an odd thing to do. For me, understanding this question is a good indicator if someone "gets" agility or not. Scrum teams should be autonomous and self-organising, so it is important to talk about what you did because it may very well impact what someone else will do.

What will I do today to help the Development Team meet the Sprint Goal?

This, of course, is the question at the heart of daily planning. It is important to know this for many reasons:

  • Perhaps the work you are planning on doing has dependencies with other on-going tasks;
  • Perhaps the Product Owner wants you to focus on another higher-value item first (for any reason);
  • Maybe you need to go to your kid's school play in the evening and it is important for the team to realise you will deliver slightly less than usual.

Who knows? I could come up with 1001 reasons with it is important to know this information.

Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

I actually do not like the word "impediment". I'd prefer it if this question was something more like, "Have I learned anything that might prevent the Development Team from meeting the Sprint Goal?"

  • Over commitment in Story Points?
  • Overly complex dependencies between tasks?
  • Summer holiday you forgot to take into account during Sprint planning?

The potential list is endless.

So What's The Problem?

Whilst I do not like that these questions are somewhat prescribed in the Scrum Guide, you're gonna have to go a long way to tell me that they are not worthy. Of course the meeting itself is also worthy. So what's the problem? Why brand these "Three Questions of Doom"?

In short: ScrumMasters actually ask these questions. They should stop.

Have you been in a Daily Scrum where you felt the Daily Scrum was reporting meeting because the Scrum Master fired these questions at you? If you have been doing Scrum for a while, I bet you have at some point! In case I was not clear the first time, I will say it again: the Daily Scrum is a planning meeting. All too often these are becoming status updates and even worse reporting meetings (important cultural different between updating and reporting). If the team members feel they have to report to the ScrumMaster (or the Product Owner) there is something wrong. You might be successfully delivering a mechanical Scrum but you have some cultural problems that are going to hurt you in the long-run.

By actually pitching these questions at the team members, the ScrumMaster is most-definitely turning the Daily Scrum into a reporting environment.

So How Should We Run The Daily Scrum?

Well, there are plenty articles out there with some good tips. I think, in short, the culture of the meeting needs to be one of "let's come up with a plan for today" not "let's report on progress". The Three Questions of Doom are useful because they illicit the information required to perform daily planning. But they are also problematic if they are used as the structure for the meeting.

So:

  • talk as little as possible, but talk about everything that is important;
  • shake up the order of the meeting;
  • rotate who is facilitating the meeting;
  • remember your time-boxing;
  • the output should be a shared understanding of the plan for the day and that is all.

By keeping the meeting lively, informative and brief, your teammates will continue to show up. If they start to vote with their feet and skip the meeting you know you have a real cultural problem surrounding one of the most important planning meetings in Scrum! Treating the Daily Scrum as a reporting meeting is one of the common indicators that an organisation has not fully understood and adopted Scrum yet. In such an environment, sadly, it is all too easy for the inexperienced ScrumMaster to fall into the trap of establishing themselves as a manger rather than a facilitator; an important cultural difference in a framework of equals.

Thursday 24 September 2015

We Need To Talk About Scrum Nexus

Life is full of little mysteries:
  • Why do cats love boxes so much?
  • How do dolphins sleep?
  • Where did the missing footage from the Zapruder film go?
  • How on Earth should we scale Scrum?

Science and conspiracy has answers to all of these. Personally, I have a few questions about the last issue.

Scaled Scrum

There are multiple approaches to scaling agile projects "out there". I'm not going to talk about any of them in detail. But feel free to take 10 minutes to educate yourself by clicking the links below. You'll come back, right?

Back? OK.

I'm particularly interested in LeSS, SSwS and Nexus (and somewhat in the Spotify approach) because these are, in particular, approaches to scaling Scrum. Of course each has its ups and downs. Nexus, however, has some particularly down-y downs. They bother me.

Getting Down With Nexus

The Nexus Framework from Scrum.org

So. Nexus. This is the official approach to scaling Scrum from the nice folks at scrum.org. It only landed very recently so it is kinda late to the party. I get the feeling it is a somewhat rushed reaction to all the other approaches coming into use first. Why do I think this? Because of two gaping holes:

  • Nexus does not actually scale (very well).
  • It will kill the culture of your existing Scrum project.

Nexus is very workable because it is so simple. It takes all the same principles of Scrum and simply add some bits. No major overhaul. No demanding concepts in addition to Scrum. But these problems of scale and culture are big problems.

Scaling With Nexus

Why do I think Nexus does not scale very well? Simple. The authors of the framework say so themselves! Take a look at what it says on page 2 of the guide:

Nexus is a framework consisting of roles, events, artifacts, and techniques that bind and weave together the work of approximately three to nine Scrum Teams working on a single Product Backlog to build an Integrated Increment that meets a goal.

Three to nine teams. THREE. TO. NINE. So between 15 (bare minimum) and 81 (absolute maximum) developers. Not very scale-y. Spotify with its 1200 developers laughs in the face of Nexus.

Why does it not scale so well? Simple: take a look at the image above. See that "Nexus Integration Team"? There's your problem. This team is constructed from the Product Owner, the ScrumMaster and the Nexus Integration Team members, who may or may not be members of the Scrum teams. For me, it makes sense for the NIT members to also be representatives of the Scrum teams. But a combination of Brooks' and Conway's laws limit the size of the NIT to about 8 or 9.

I have yet to see anything official on the matter but I have heard rumour of Nexus+ as a means for bringing greater scale. A Nexus of Nexuses. Holy Moly. No.

Culture Vulture

The one is subtle. And little hard to explain to anyone who has never "done agile". But I'll give it a try.

Scrum teams are self-organising. This is a big deal. They work together to solve their problems as best as they can. The most "senior" team members humble themselves and the most "junior" have the chance to shine. Everyone pulls together and does their best using their skills. No specialists.

I call this the "egalitarian social contract" of Scrum.

You will not find any Scrum guide telling you that this is a feature of Scrum. It isa natural result of being self-organising (something which the guides will tell you to do). "I hate being in a team of equals" said no Scrum team member ever. This attitude to teamwork is something that is just expected of a Scrum environment with decent values.

Nexus kinda breaks this. Hard. And explicitly.

Go back to that guide again and take a look at page 5:

Members of the Nexus Integration Team may also work on the Scrum Teams in that Nexus, as appropriate and necessary. If this is the case, priority must be given to the work for the Nexus Integration Team. Membership in the Nexus Integration Team takes precedence over individual Scrum Team membership. This preference helps ensure that the work to resolve issues that affect many teams has priority.

Priority must be given to the work for the Nexus Integration Team. Priority. "Sorry guys, I need to do some stuff for the NIT. I'm not going to be able to help with backlog item X today." Not. Cool.

All That Bad?

If I am being honest, this is a little bit of nit-picking on my behalf. Scaling up to 81 is still more scale than the vast majority of development companies need to scale to. Cultural problems can always be tackled somehow. I guess my issue is that these problems were built in to the framework.

I'd love to see Nexus in action. I suspect it is so new that nobody is really doing it yet. Is anyone out their seriously wanting to give this a try? I hope so. Please shout if you are. I'm really curious to see it in action.

Wednesday 2 September 2015

Judas Priest Ate My ScrumMaster @ Write The Docs

This is the first of two blog posts I will write about Write The Docs Europe. I'll kick-off by writing about my presentation, but later I will write about my views of the event as a whole.

Background

I spoke at the Write The Docs Unconference in Berlin last year. At the time I talked about how Free Software projects emerge from an idea to success and some of the "laws" they abide by in order to get there. As part of that presentation I wanted to begin my personal journey of better-understanding the "laws" followed by tech writers. The subsequent workshops around this topic produced some interesting results for which the results can be read here.

In Prague I wanted to move from a "pull" to a "push" model and presented some of the laws that apply to software engineers (not just Free Software).

Presentation & Notes

  • Slide 2:
    • I come from the engineering perspective, not the tech writing perspective
    • I am here to learn and to improve my own working practices
  • Slide 3:
    • Sturgeon's Law
    • Really, "10% is where we add value"
  • Slide 4:
    • Management is very important in Free Software
    • See myself as a community manager, but many would not
    • I'm not a cat-herder, I focus more on "classical" management in Free Software
  • Slide 5:
    • Document writers are all just as individual as software engineers
    • Just like engineers, however, they share common problems < something I learned at Write The Docs Berlin
  • Slides 6 - 10:
    • Hopefully, self-explanitory
  • Slide 12:
    • Notice something about these laws of software engineering?
    • The context they were written about is software engineering... but really these laws have nothing to do with software engineering!
  • Slide 13:
    • Lehmann's 5th law: teaches us that all stakeholders in the development process (and this definitely includes tech writers) must continue to master the product for it to remain competitive
  • Slide 15:
    • I love Free Software and Open Source as concepts
    • But the names are engineering biased: "Free Software", "Open Source"
    • As these forms of licensing/development become the norm the terms will become irrelevant
    • When this happens, we must ensure that our focus is on Free/Open products, for which excellent documentation is crucial

Reaction

Wednesday 19 August 2015

Ignite Berlin 5: The Video Evidence

Miss my talk at Ignite Berlin 5? Well here's your chance to see the recording. A quick reminder:

  • 5 minutes
  • 20 auto-forwarding slides
  • An open minded crowd looking for interesting content and a little entertainment

This was a really difficult talk to prepare for. I would use this many slides in a talk that is waaaaay longer than 5 minutes. In this format, the speaker is basically forced to tell a 5 minute story and ensure ("hope") that the story progresses at the same pace as the slides.

If you head over to Peter Bihr's account on YouTube you will find all of the other talks from the same event. I highly recommend the talks from Claudia (on typewriters) and from Jessilyn and Neil (on how to ale long-distance work).

Also, in case you have not seen it, get yourself over here to see an article on the original concept art for Pac-Man. Cool stuff.

Thursday 6 August 2015

No Onion In My Salad: Write The Docs Redux

I was very pleased an humbled to read this recently: I spoke at the Write The Docs unconf in Berlin a year. It had been a long time since I had spoken at a non-engineering event. Even longer since I last spoke at an event without an explicit Free Software connection, too. I enjoyed the event and I obviously did not make a fool out of myself, because I am due to speak at the next Write The Docs European conference in Prague.

What Happened in Berlin?

Last year I gave a talk about growing communities of (Free Software) engineers and about how community works in engineering. At the time I posited that collaboration between software engineering and documentation writing can be improved if we improve our understanding of each other... https://speakerdeck.com/padams/no-onion-in-my-salad-how-to-manage-emerging-communities ...which led me to ask some questions at the end. After my presentation during the "unconference" part of the unconference a group of us sat down to try and answer one of the questions I posed in my presentation:
What are the rules documentarians play by?
If you follow the link in the Tweet (above) or follow this link here you will find Nigel's report on what we concluded in that session. OK, so I learned a thing or two about how documents are prepared in the software product world. Cool. What's next?

What's Happening in Prague?

Well, if we are to improve understanding between document writers and engineers there needs to be a little "push" as well as "pull". That's where my talk in Prague comes in. Having learned something about how document writers behave/work, it is time for me to return the favour. In "Judas Priest Ate My ScrumMaster" I will talk about some of the "laws" of software engineering and what they mean, in reality, for engineers "on the ground". Do these same laws apply to document writers? And, if so, could they form the basis of a common understanding between those writing the software and those documenting it? Could this common understanding lead to improved collaboration and better processes? Let's find out in Prague!  

Friday 31 July 2015

Ignite Berlin #5

Ignite is a really interesting set of events held in over 100 cities globally. Unashamedly aimed at geeks, speakers are asked to have a point to make, but make it quickly! 20 slides, auto-transitioning every 15 seconds to give a 5 minute talk. I gave a talk on Pac-Man and how a programming error made it impossible to win. I already had the content/knowledge and was inspired by a similar presentation I saw at Enthusiasticon. The evening was split into two halves: the first seven talks were a mixed-bag on topics as varied as bees (and beekeeping), pole dancing, love (and death) and, of course Pac-Man; the second set of talks related to the importance of typewriters, supporting kids as the next generation of hackers, why the future of innovation is not just "dinosaurs" and "unicorns"... and much more! Special kudos goes to the couple who gave a talk on how they maintain their long-distance relationship through music. Ignite 5 was a really fun event. Content came quickly and slickly. Audience of roughly 100 was very receptive given how wide-ranging the content was. I'd go along next time for sure. Given that it is a "mixed-bag" I'm not sure I'd actually like to know what is being presented in advance... Just turn-up and see what happens!

Friday 24 July 2015

Agile Estimating and Planing (Part I: The Problem and the Goal)

For all engineers working at KDAB, "The Clean Coder" is compulsory reading. It is a very interesting read because it is almost a lifestyle guide, rather than the usual dry text on personal time management. It covers all the common tasks faced by software engineers: estimating, refactoring, testing, coding... the lot. As proclaimed by the back cover, "[the book] covers more than technique: it is about attitude." It's a great introduction to software craftsmanship. Impressed with this book, I picked up a copy of "Agile Estimating and Planning" which is in the same series of books from Prentice Hall.

The book is separated into 7 parts and 23 chapters. I will not bombard you all with a lengthy review of the whole thing all at once. Instead, I'll drip-feed you my thoughts one part at a time. Starting with the beginning: "Part I: The Problem and the Goal".

Chapter 1: The Purpose of Planning

This chapter should provide nothing new to anyone who has been through "Project Management 101" and is nicely couched in the context of software development. Ultimately we are asked "Why bother with planning at all?" and are presented with the following reasons:

  • Reduce risk
  • Reduce uncertainty
  • Support better decision making
  • Establishing trust
  • Conveying information

Fred Brooks (in a pre-agile era) famously told us that we needed to throw one plan away, so we should plan to do so:

The corollary to this is that if you plan to throw one away, you will end up throwing away two.This is and has been an impractical suggestion. Plan to build something as quickly as possible and modify it as needed in the future.

Planning is very important. Plans are not. Fred Brooks saw agility coming. Hero.

Paul's Thoughts...

Good introductory chapter. Gentle reminder of a few things the reader should probably already know. Successfully sets the context for what is coming.

Chapter 2: Why Planning Fails

So now we start to get a little more in-depth with agility. Again, nothing too taxing at this point and certainly familiar ground for anyone who is an experienced ScrumMaster or Product Owner. This time we are simply asked "Why does planning fail?" There is, of course, plenty evidence for failed planning: how many people reading this have been involved in projects where scope, quality and/or timelines have been "off"? I know I have. Let's face it, we all have.

In this chapter the primary reasons for failure are cited as:

  • Planing activities and not features
  • Too much multitasking
  • Features not developed by priority
  • Not embracing uncertainty
  • Estimates as commitments

The second point on this list is my favourite and one that often goes misunderstood... Once upon a time I thought I was Godlike for handling so much work. I was the multitasking master. Education and experience has taught me that multitasking is actually the productivity killer. Do one thing. Get it done. Move on. I actually control my tasks at work with a Kanban chart which has been specifically designed so that I cannot fit too many tasks into the "Work In Progress" state. In short: multitasking causes a lack of focus, increases the number of ramp-up periods/context switches, increases stress and, most importantly, delays the delivery of results, which may impact other people's work. The book contains a genius "why did I not think of that?" diagram to illustrate this.

Paul's Thoughts...

Great reminder of the factors behind planning failures and good description (without too much tedious detail) of why these factors happen in old planning styles.

Chapter 3: An Agile Approach

A good plan violently executed now is better than a perfect plan executed next week. --- General George S. Patton

Chapter 3, opens with an epic quote. Otherwise, the first half of this chapter is a little unnecessary; the history and fundamental concepts of agility are presented. In all honesty, I skipped through a lot of this. There is nothing new in here and it is all content I would expect the reader to have a good grounding in. I assume this was thrown in "just in case" the reader gets this far with no knowledge of agility at all.

Thankfully the second half of the chapter gets us back on point.

In the second half of the chapter we are reminded that planning is actually only as useful as the horizon; if you are trying to reach a target 20 miles away, you're going to need to check your progress and reassess 5 times, because the horizon is roughly 4 miles away. So what are the horizons in software engineering projects?

Paul == Artist

Typically it is the three innermost of these that we care about. The inner two are certainly familiar with any Scrum practitioners (daily scrum and sprint planning/retrospective). Release planning is about determining what user stories are going into the next version of the product. If anything, it is about creating a "vision" that the team can buy into. Iteration planning is more in-depth: "What are the tasks we can associate with the user stories? What are the priorities?". Daily planning is hugely important, too: "What am I working on? Who/what am I blocking? Who/what is blocking me? Is progress as expected?"

Paul's Thoughts...

An interesting read for anyone who needs an introduction to agility and how to structure planning in an agile environment. I was left thinking "just cut to the chase!". The next part of the book, and my next post on this topic, is called "Estimating Size". Now we're talking!

Overall Thoughts on Part 1

It is satisfying to be reading a book that I can easily relate to my own experiences of both classical and agile project management. The background information is undoubtedly important for some readers. For me, however, there was just a little too much. Any experienced project manager (especially Scrum Masters/Product Owners) could skim through this and head straight to Part II, I think.

Monday 20 July 2015

A Tale of Two Talks

My day-to-day contribution to Free Software has changed quite dramatically in the last couple of  years. I'm no-longer as involved with any one project than I used to be. Somewhat correlated with my declining active contribution to Free Software projects is my decline in public speaking.

You wait forever for a bus and then two come along at the same time!

I shall be delivering two very different talks in the coming months: one in which I will remind the audience that PacMan is a real asshole and in the other I will talking about documentation communities within Free Software.

"PacMan: The Original Troll", Ignite Berlin

Thursday, July 30th at 19:00. IXDS studio, Paul-Lincke-Ufer 39/40, 10999 Berlin
"PacMan: The Original Troll. PacMan is one of the best-known, well-loved and often-copied games of all time. But PacMan is mocking you. You cannot beat PacMan; nobody can beat PacMan. He laughs in your face."
I recently attended Enthusiasticon where one of the talks was about Pokémon and, more specifically, about how a programming error (almost certainly caused by an engineer wrestling with the GameBoy's very limited architecture) made the game bizarrely winnable. If you knew how. This inspired to get up and talk about PacMan; a game which has the opposite problem.

As an Ignite talk, I will only have 5 minutes. PacMan needs no introduction, so I can save some time there. So I will cut straight to the ghosts, the map and why you're doomed to never beat PacMan.

Spoiler alert: the "waka waka" noise that PacMan makes... that's him laughing in your face.

More of the event details can be found at the Ignite Berlin website.

"Judas Priest Ate My ScrumMaster", Write The Docs Europe

Monday, August 31st and Tuesday, September 1st at 09:00. Club Lavka, Novotného lávka 201/1, 110 00 Prague
"Community Management in Free Software communities is still an emerging field and has produced a spectrum of practitioners: from master-manipulators of social media, to those more focused on metrics and data as a means to driving process. Either way, the state of the art is still largely driven by the needs of technical contributors to projects. Good documentation is a crucial component in a software product and yet often technical writers are overlooked as important stakeholders of the process. Within the community, there are undoubtedly common problems between engineers and technical writers. Software Engineering is full of laws; can we show that these laws apply to technical writers as a means to help bridge the chasm between developers and technical writers?? In this talk Paul walks us through a selection of his favourite laws of software engineering and explores how developers measure them and if technical writers must also obey them. Or not. And what that means for the success of documentation in a Free Software project."

This will be the second time that I have spoken at a Write The Docs event. These are very friendly events and very welcoming given my "deliberate outsider" position. As a software engineer I think it is fun and useful to engage with events like Write The Docs in order to reach and say "here is how I think document writers and engineers can work together better" from the engineering perspective.

In this particular talk I will be exploring some of the rules and laws of software engineering and showing how I think these laws equally apply to document creation. Do these common problems create a bridge between document creation and coding? A common "platform" to work from?

Spoiler alert: 90% of this talk will be crap.

More of the event details can be found at the Write The Docs Europe website.

Sunday 19 April 2015

Evolving KDE: Lehman's Laws of Software Evolution In The Community

The board of KDE eV has launched a new initiative to ensure that KDE remains awesome and relevant for the foreseeable future. Unlike previous approaches it is not a point-in-time solution, it is a continuous process of improvement. And it is a good thing.

Previously, I have written/spoken a lot about the role of Brooks' Law in the context of Free Software. Brooks' Law teaches us to be careful about the management of growth in our communities. Especially treated in consideration with the grossly under appreciated Conway's Law. There are, of course, other laws of Software Engineering that apply to Free Software development.

Last weekend I attended the KDE eV board meeting held in Berlin. I was part of a team of KDE community members who provided our thoughts on the board's desire to ensure the overall KDE community continues to work effectively and continues to deliver awesome software. A lot of the discussion involved the word "evolution". Now the context was the community... but our software continuously evolves, too. What are the implications on this for a Free Software Community? And are community evolution and software evolution somehow linked?

What's Your Type?

In the 1970s it was formulated (paywall, sorry) that any piece of software will fit into one of three categories:

  • An S-program: written according to an exact specification of what that program can do;
  • P-program: written to implement certain procedures that completely determine what the program can do (the example mentioned is a program to play chess);
  • An E-program: written to perform some real-world activity; how it should behave is strongly linked to the environment in which it runs, and such a program needs to adapt to varying requirements and circumstances in that environment.
(Source Wikipedia)

Now a Free Software project could, in theory, fall into any of these. I want to focus on KDE which, arguably, is almost entirely E-type software: software that must evolve to satisfy its shifting environment.

The Laws

So let's take a look at Lehman's Laws and what they mean for Free Software. I'll couch them in terms of KDE as much as I can. Please note: this is not scientific, just my thoughts on what we can readily observe in the wild and what it means. This is also not exhaustive; I'm cherrypicking a selection of the laws.

Continuous Change

an E-type system must be continually adapted or it becomes progressively less satisfactory

In this context "change" can mean various things: adding features, removing features, QA improvements... I'm not going to single out any particular parts of KDE, but I think it is fair to say that parts of our technology have failed to remain competitive because activity declined (and, thus, "change" with it). More positively, I think it is very easy to point out that much of KDE remained competitive because it did change; it's not very often that a part of KDE becomes completely moribund.

Increasing Complexity

as an E-type system evolves, its complexity increases unless work is done to maintain or reduce it

Refactor, refactor, refactor. Once of the things I love about KDE is we are always marching forwards. We are very focused on staying competitive by adding new features or by reinvention. That's not to say we ignore Bugzilla, however. Time is always being spent in bug fixing. But what about other QA activities? The fine-polishing work is not consistent. Take, for example kdelibs. Large scale refactoring took place during the switch from Qt4 to Qt5 because, I assume, during there Qt4 lifespan of kdelibs, focus was on other things. KDElibs are now more competitive than ever and widely applicable to anyone doing Qt development.

Conservation of Organisational Stability

the average effective global activity rate in an evolving E-type system is invariant over the product's lifetime

This one is a little tricky to explain. Perhaps a better presentation is this:

Beyond a certain upper limit, adding more resources or effort does not benefit the system in a meaningful way.

To be honest, I have no examples of this ever happening in Free Software. Ever heard of a project (legitimately) saying "You know what, we don't need more contributors." I would love to hear any examples people have.

Something to note: this is distinct from Brook's Law. They both relate to the growth of the team, but the context is very different between them.

Conservation of Familiarity

as an E-type system evolves, all associated with it, developers, sales personnel and users, for example, must maintain mastery of its content and behaviour to achieve satisfactory evolution. Excessive growth diminishes that mastery. Hence the average incremental growth remains invariant as the system evolves.

The text of this law focuses on the effect of excessive growth: if you make too great a leap in your development you may end up lowering satisfaction. I think it is fair to say that is precisely what we experienced when KDE moved from KDE3 to KDE4. The Gnome community have seen something similar in the last few year's too, I think. This is not news to anyone... radical changes carry risks.

I like to think of this law from another angle, however. Too much growth will reduce satisfaction and, likewise, will a reduction in developers familiar with the codebase. Developer turnover can be even more dangerous than overreaching, in my opinion. Any of my previous green/blue blobs postings will give you an idea about developer turnover in various KDE projects.

Evolving Evolution (Or, "What's This All About, Paul?")

I recently read this article on culture inside Open Source communities. There are plenty examples of  projects/companies with that kind of messaging who genuinely mean it. There are, sadly, also examples of where Shanley is totally right. E-type software has an environment (most importantly, including users who interact with it). The environment is always shifting and the software must shift with it to remain relevant (the law of "continuous change"). Users generally do not like it when their software does not move with the times. But (the law of "conservation of familiarity") don't change too much! It's a fine balance and it is largely driven by continuously assessing the position of the software in the environment and understanding where to go next (the law of "feedback", not previously mentioned).

Projects and their communities evolve out of necessity. Engagement with the wider world drives this. I suspect most developers reading this will say "yup, that makes sense" for each of these laws. What they might not do, however, is realise the link between the laws and the overall culture of their project. It's a strange thought, but it is true...

Some projects want to ship a product. Some want to ship innovation. When you fire up Emacs and start writing that killer new feature rather than refactoring that spaghetti code you are, probably unconsciously, contributing to the overall culture of your project. Perhaps your community has a substantial focus on QA rather than innovation. Or maybe a balance of the two. Do you want to allow new contributors to join any part of the project they want and find their own way? Or do you want to focus on guiding them towards where effort is needed? There is no right or wrong.

But there are definitely users and you definitely need a mechanism for reacting to their needs and staying relevant. Why? Because wilfully choosing to become irrelevant ain't cool to the people/organisations who rely on that <thing> you wrote. If your users are crying out for more stability and you keep shipping new features instead, you're gonna run int trouble somewhere, sometime.

In Conclusion

A software evolves and so must the community. Lehman's Laws could, arguably, apply to both. Why? Well, at the very least, Conway's Law implies symbiosis between community structure and product.

  • Continuous Change: The KDE community must always evolve...
  • Increased Complexity: ... in a controlled manner. We must always adapt ("refactor") the community to suit the needs of the challenges we address
  • Conservation of Organisational Stability + Conservation of Familiarity: We must drive forward, we must grow and we must adapt, but we must also keep in mind that experience is precious and we should support our most experience contributors as they support the next generation of users.

Monday 23 March 2015

Akademy CfP: Deadline Approaches

Another year, another opportunity to annoy Nuno Pinheiro with some terrible "engineer art" that I produced many moons ago (see header image). This, my friends in KDE, is why you should be going to Akademy and why you should talk there.

Akademy: The Social Heartbeat of KDE

Akademy, in short, is the annual conference of the KDE community. If you are interested in KDE, you should go. If you contribute to KDE, you should definitely go. Why? Because Akademy is the event where we have the opportunity to evaluate our position and to look forward, in a face-to-face manner. It does not matter if you work on libs, or Plasma or that game. What is important is that this is the location for getting your voice heard.

Three major ways of doing this:

  • Take part in the eV AGM which is always co-located with Akademy. I will spare you another lecture on what the eV is and why it is important. If you understand why the eV is important, you will understand why it is important to be at that meeting and to contribute your voice to the effort of supporting the wider KDE community.
  • The hallway track! Do not underestimate the power of the hallway track at Akademy. Between talks, over lunch, at the end of the day before you grab a beer... Whenever. The hallways of Akademy are always filled with the noises of people discussing KDE and where they want to see it go.
  • And, finally, give a talk! It is this final point I am writing abut today...

Happy Talk, Keep Talking Happy Talk

So there is a shiny shiny Call for Papers. On there you will see my name; I'm part of the committee evaluating talks. There are some specific topics we mention in that CfP that we would love to see people talk about. However, it is worth remembering, I'm a simple dude. Personally, I'm looking forward to seeing what people want to talk about. So submit your talk on anything, so long as it is relevant and interesting to the KDE community.

Akademy is very good at producing navel-gazing content. And I have no problem with that at all. This event is our one opportunity each year to evaluate where we are at. But it is always great to get more visionary content, too.

Where is Plasma going?

The Strategy

We have three (actually it is four) different types of content planned for this year's Akademy. Here is how I would think they are best used:

  • Workshop: 30 to 120 minutes. This is for the hands-on stuff. Want people to make better use of your library? Perhaps you want to run a tutorial on the basics of creating a plugin for Akonadi. Or whatever... This is what you should be submitting if  you people to have a hands-on experience.
  • Talk: These will mostly be 30 minutes, but might be longer in certain cases. These are the perfect avenue for forward-looking content, in my opinion. Want to start a discussion around where your part of KDE is going? Then submit one of these.
  • Fast Track: These are great for the "here is where I'm at" content and are 10-minute presentations; a report on the status quo. Perhaps you want to give a brief update of something you announced in a previous year, for example.
  • Lightning Talk: Often overlooked, Lightning Talks are hugely important. For me, they are all about ideas. You have got 5 minutes to make people interested in your idea. They are, in essence, food for thought and inspiration for the hallway track.

Time Is Running Out...

The deadline in March 31st. So get those talks in. And soon.

So, if there is something you want to talk about at Akademy, submit a talk. Submit many talks! This is your primary opportunity for the year to get your message across and make a difference to the future of our community!

In Conclusion

Last year we had an entire track dedicated to oxidised brass instruments. Important stuff.

Friday 6 February 2015

The Who and When of Amarok

Strange things happen while at FOSDEM...

...like losing that prized community visualisation code you've been tinkering with for years.

Shifting the bits about

Short version:

  • Ditch office machine ("Sitzplatz")  and turn it into a box for Windows/Linux built and test;
  • Send laptop ("Feuerameise") back to KDAB UK (I'm now on the KDAB Germany payroll);
  • Take home office machine ("Kraftwerk") into the office;
  • Get new laptop ("Entwerter") for home/travel use.

Backing up and merging all the datasets between these machines without a hitch... apart from losing my log parser and visualisation code. So, I spent the last couple of hours rewriting them all. I used Amarok for test input data; not too much, not too little, just hmm-mmm good.

No comment, just sample output from my nearly-complete rewrite of my tools. Needless to say, I was listening to Spotify while visualising Amarok. (Click to enlarge).

You will notice that, at some point, the date format changes in the repo. I'm guessing this coincides with the switch from SVN to GIT. Speaking of coincidences... Look at the "performance" of Mark Kretschmann, the project founder. Project activity appears to be falling over recent years but, when Mark appears to stop work, the whole thing grinds a halt. Coincidence? Nope.