Archive of published articles on November, 2013

Back home

The Flawed Project-as-a-Ship Analogy


It is common for a project leader to see his or herself as the captain of a ship. The project is seen as the ship, and the developers are the crew. When storms hit- the project is behind schedule, over-budget, below quality, falling short of projections and expectations- the captain doubles down and starts to behave more captain-like to stabilize the ship.

There are many bad practices software development captains use to navigate stormy seas. Perhaps the worst of them is to silence dissent and remove “poor performers.” The idea is that by silencing dissenters and removing poor performers, you create smoother sailing for the ship overall, to help ride out the storm.

Unfortunately the ‘project as ship’ analogy is fundamentally flawed. The project is not the ship. The people are the ship. When you remove dissenters, you are ripping out vital structures. You are destroying your sails and your rudders. When you remove “poor performers”, you are throwing out vital reserves that you should instead be better utilizing. You are ripping holes in your hull. When you ‘cut back’ on investing in your people, you are foregoing essential maintenance and leaving your ship in disrepair. The project itself- the artifacts people create- has no place in the ship analogy. The project is a result of an equation of people, not a factor in it.

Focusing on stabilizing the project in times of trouble, rather than growing and nurturing the people that create it, doesn’t make for smoother sailing. It makes for a sinking ship.


Spotify’s DNA of Autonomy and Collaboration


Anders Ivarsson, an Agile Coach from Spotify, was kind enough to present his talk from Agile Ísland at our company on Friday morning. It was ostensibly about “scaling agile” but really it was a talk about how they’ve created a culture that prizes autonomy and collaboration.

I’m personally tired of hearing about how new, growing, successful businesses do things. In most cases, these evangelists really have no idea, and all you get is a post-mortem about choices a company made and tools they use, wrapped up in a presentation that these choices are integral to the company’s success and you should listen. In reality, most of the choices are made for no real reason, it’s just the way things turned out, and who knows if the company is successful because of these choices or in spite of them. And of course we don’t know if these choices led to an actual profitable or sustainable business or how they adapted to times when money wasn’t pouring in.

I felt different about this Spotify presentation even though it fit the mold. The reason is because Anders spoke very little about agile tools and very much about how the company is structured around autonomy and collaboration. Autonomy and collaboration are built into organizational structure. It seems monumentally difficult to create a command-and-control environment at Spotify. You’d have to restructure the entire company, top to bottom. Which means that a few bad apples (any company doubling its size every year has more than a few bad apples) won’t ruin the bushel. It would take a concerted effort of senior management to change that DNA, not a few incompetent bad hires.

This is the total opposite to most agile success stories you probably know of, where success is limited in area but especially depth and time, because most people are working in a command and control structure (even if the company doesn’t necessarily operate in a command and control fashion). Without structural reform, you can’t really do more than scratch the surface of truly agile or lean changes. And without structural reform, when a bad apple comes along into a ‘command and control but currently agile’ situation, all progress can be wiped away and it is incredibly easy to slip, almost immediately and without anyone observing, into a command and control system.

No Comments

A use for killing tasklets


A few weeks ago, I posted about Killing Tasklets, a feature of Stackless Python that allows you to abort a tasklet at any point. And it turns out I had a perfect use case for them just last week and things went swimmingly well.

We have a client program that controls the state of 3D objects, and a server program that does the rendering. The client calculates a serialized version of the server’s state (based on the client’s state) and sends it to the server. It does this through a publish/subscribe. The server receives the state and applies it to the current scene, moving objects and the like (of course we have other mechanisms for rebuilding the entire scene, this is just for ‘updating’ the attributes of the current object graph).

This causes a problem when the server takes longer to apply the new state to its scene than it does for the client to calculate it (maybe the client is super fast because it is caching everything). The server lags further and further behind the client. So when the server receives the ‘update’ command, it kicks off and stores the tasklet to do the updating. If another ‘update’ comes in while the previous update’s tasklet is still alive, it kills that tasklet and starts a new one. This way we get as smooth an updating as possible (dropping updates would cause more choppiness). This does require that updates are ‘absolute’ and not relative to other updates, and can be aborted without corrupting the scene.

Killing tasklets turned this into very straightforward code. In fact none of it other than the few lines that handle subscriptions on the server know anything about it at all. This sort of “don’t think about it too much, it just works like you’d expect” promise of tasklet killing is exactly why I like it and exactly what was fulfilled in my use case.

No Comments

Balancing Team Autonomy and Centralized Control


What is a leader on a multi-team Agile project supposed to do when there’s an expectation to make decisions that would bind all teams and for which he or she cannot hope to consider all viewpoints?

I often found myself in this position with generally two types of decisions to make.

The first were technological ones. These were easy because ultimately the work directly impacts a specific group the most. You just find that group, who of course are doing the work and understand the problem best, and just support their decision. It is well known that the people closer to doing the work have better information to make the decision. If you don’t trust them to make technological decisions, you are pretty screwed and should work on that. I was fortunate to have a very talented group of engineers that I fully trusted.

The second type were usually development decisions that did not have clear answers. Coding style, review process, Agile processes, etc. Decisions where everyone is a stakeholder. In these cases, I would always discuss the topic in an open forum, such as the relevant Community of Practice, or even via email. I would then take the decision of the group and make it “official policy.”

It’s important that these discussions not discipline discussions, or leadership discussions; they must be open discussion in a zero-barrier-to-entry forum. It is like early RFCs: if people are interested, they can discuss. If they are not interested, they do not have to take part, but they will have to abide by it. It was also my policy to revisit decisions every few  months (maybe 6 for project-wide changes, or 2 for changes scoped to a team or two). This way people would have less fear of change. If something doesn’t work out, we can always go back to how it was. Where decisions were made on a discipline level, or the expectation to revisit these types of decisions wasn’t made clear, I think development decisions did not work well.

I feel this style of decision making walked a good balance between:

  1. Actually making decisions. It’s too easy for Agile project leadership to hide behind “team autonomy” as an excuse for not making decisions (technological, developmental, or otherwise) or being held accountable.
  2. Respecting team autonomy. Ideas could be piloted on not-unwilling teams with the understanding that things could go back to how they were if they don’t like it.
  3. Consistency between teams. We could force changes across teams, creating consistency where beneficial, without feeling so bad, because everyone who was interested could have a say.

This is what I aspired to, at least. And when I followed it, decisions tended to be positive. When I lost sight of it (or before I gained clear sight of it), my decisions were pretty average.

No Comments

Killing Tasklets


Today at work we had a presentation from the venerable Kristján Valur Jónsson about killing Tasklets in Stackless Python, a technique he and partner-in-crime Matthías Guðmundsson started using for their work on DUST514. As someone who’s done some asynchronous programming, this idea sounded blasphemous. It took a little while to stew but I see the value in it now.

The core idea is really simple. Code invokes the kill method on a tasklet. All kill does is synchronously raise a TaskletExit exception (which inherits from BaseException so as not to be caught by general error handling, same idea as SystemExit) on the tasklet. This bubbles up to the Stackless interpreter, and is caught and swallowed.

There are details of course, but that’s the gist. There are a few reasons I like this so much.

First, it uses standard Python exception handling. It’s really easy to explain and understand, like no question about finally blocks being executed (they are). The fact that the killed code runs and dies as I expect makes this at least something to look at.

Second, it can be synchronous. There’s no ‘kill and spin until it’s not alive’ type of thing. When you tell the tasklet to die, it faithfully obeys. You are Thulsa Doom. You can kill it asynchronously but the fact that synchronous behavior works in such a straightforward way is a big thing.

Third, it actually cancels the tasklet where it is. You cannot replicate this with some sort of cancellation token or flag, which always has some delay if it supports cancellation at all. It not only simplifies things but makes them work totally as desired. So even if you are theologically opposed to Tasklet.kill and prefer other disciplined techniques for writing async code, you can’t argue with the superior results.

In the end, you still need to write good code and maintain discipline about shared state and side effects, but I see not only the value in killing tasklets but the superiority of the choice. I hope Kristján (and also Christian Tismer, the other Christian primarily responsible for Stackless) do a more thorough talk about killing tasklets at some conference.

1 Comment