Category Archives: working life

Deep Learning & Unintended Algorithm Bias

This was a 5 minute talk on deep learning for the very excellent @chesterdevs. Like others talking about deep learning, I took visuals and the face-learning example from the landmark 2012 paper, Quoc Le/Google/Andrew Ng paper, “Building High-level Features Using Large Scale Unsupervised Learning.”

Only afterwards did I notice that the subset of images which their system show as “most like a face” from their test set were 90% male and 90% white, as is the prototypical face that the machine outputs.

And so we have a neat demonstration of unintended algorithm bias: their input was 10 million randomly-chosen youtube videos; the output was white and male. I bet they didn’t expect that.

A salutary reminder that—as the hard-working statistician will tell you—“random selection” does not mean “unbiased”.

Conway’s Law & Distributed Working. Some Comments & Experience

The eye-opener in my personal experience of Conway’s law was this:

A company with an IT department on the 1st floor, and a marketing department on the 2nd floor, where the web servers were managed by the marketing department (really), and the back end by the IT department.

I was a developer in the marketing department. I could discuss and change web tier code in minutes. To get a change made to the back end would take me days of negotiation, explanation and release co-ordination.

Guess where I put most of my code?

Inevitably the architecture of the system became Webtier vs Backend. And inevitably, I put code on the webserver which, had we been organised differently, I would have put in a different place.

This is Conway’s law: That the communication structure – the low cost of working within my department vs the much higher cost of working across a department boundary – constrained my arrangement of code, and hence the structure of the system. The team “just downstairs” was just too far. That distance was composed of gaps & differences in priorities, release schedules, code ownership, and personal acquaintance.

Conway’s Law vs Distributed Working

Mark Seemann has recently argued that successful, globally distributed, OSS projects demonstrate that co-location isn’t all it’s claimed to be. Which set me thinking about communication in OSS projects.

In my example above, I had no ownership (for instance, no commit rights) to back end code and I didn’t know, and hence didn’t communicate with, the people who did. The tools of OSS—a shared visible repository, the ability to ‘see’ who is working on what, public visibility of discussion threads, being able to get in touch, to to raise pull requests—all serve to reduce the cost of communication.

In other words, the technology helps to re-create, at a distance, the benefits enjoyed by co-located workers.

When thinking of communication & co-location, I naturally think of talking. But @ploeh‘s comments have prodded me into thinking that code ownership is just as big a deal as talking. It’s just something that we take for granted in a co-located team. I mean, if your co-located team didn’t have access to each other’s code, what would be the point of co-locating?

Another big deal with co-location is “tacit” knowledge, facilitated by, as Alistair Cockburn put it, osmotic communication. When two of my colleagues discuss something, I can overhear it and be aware of what’s going on without having to be explicitly invited. What’s more, I can quickly filter out what isn’t relevant to me, or I can spontaneously join conversations & decisions that do concern me. Without even trying, everyone is involved when they need to be in a way that someone working in a separate room–even one that’s right next door–can’t achieve.

But a distributed project can achieve this too. By forcing most communication through shared public channels—mailing lists, chatrooms, pull request conversations—a distributed team can achieve better osmotic communication than a team which has two adjacent rooms in a building.

The cost, I guess, is that typing & reading is more expensive (in time) than talking & listening. Then again, the time-cost of talking can be quite high too (though not nearly as a high as the cost of failing to communicate).

I still suspect that twenty people in a room can work faster than twenty people across the globe. But the communication pathways of a distributed team can be less constrained than those same people in one building but separated even by a flimsy partition wall.

References

A Manifesto for Post-Agile Software Development

— DRAFT —

In nearly 15 years since the Agile manifesto was penned, an entire generation of the software industry has grown up having known only ‘Agile’ methodologies. Their experience has not been entirely positive.

The ‘new’ criticisms made against agile – that is, by those who have grown up with it, not those who opposed it in the first place – are rarely criticisms of the agile manifesto. They are, often, reactions against the (abusive) experience of being pushed into processes, behaviours & relationships which are unsatisfactory; whilst at the same being stripped of any power to improve them.

We should always react against people being pushed about, and made powerless.

A manifesto is a small thing. It can fall on deaf ears. It can be interpreted to mean the opposite of what was intended, it can be misused to manipulate people. But if we make the effort to keep in touch with each other, and to keep trying to re-state what was meant, it can continue to be a valuable guide. And so I propose a 15th anniversary postscript.

Manifesto for Post-Agile Software Development: A Postscript

  • The agile manifesto was not and is not a prescription for people to impose conformity, nor a tool for controlling people.
  • There is a deeper theme to agile. At the core it is based on trust and respect, promoting workplace relationships which value people. We oppose methods, structures and behaviours which reduce respect and trust, and which reduce people to assets with no power.
  • Agile will always demand shared learning and shared improvement. Without critical reflection and learning – both from their own experiences and from the wider community – teams cannot remain agile. Without improvement based on that learning, ‘agile’ becomes fossilization.

Manifesto for Agile Software Development: A Reminder of the Original

The Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Comments

You may wonder why the term ‘post-agile’. It may be pointless, but it’s already in use, so we could choose to go along with those who want to learn, change and improve on their experience of ‘agile’.

As I see it, there are two essentials to agile: treating people well; and never stop learning. Each of these two is only truly possible when the other is also practised.

  • The phrase and much of the bullet point ‘There is a deeper theme…’ comes from About the Manifesto.
  • The emphasis on continuous learning is for some so obvious as to need no explanation. But some are stuck in a so-called "agile" process which they are powerless to change or improve. The irony of naming such an structure ‘Agile’ would be funny if it weren’t so painful.
    • Ron Jeffries’s reaction to criticisms of Scrum has been: "The essence of what makes Scrum work isn’t the three roles, the five meetings, the one artifact. It’s Inspect and Adapt. When things are not going as you like, you’re supposed to fix it."
    • To cry out that without continuous learning and change there is no agile, can be a powerful tool for the disempowered.
    • Calling for change in a broken process can become a step towards changing broken relationships.

Alternatives

The main alternative to a ‘post-agile’ slogan is surely Alastair Cockburn’s ‘Heart of Agile’.

A rather rushed and incomplete bibliography

Draft – Comment & Contribution Welcome.

The Known Unknowns Matrix

I’m sure that I.T. is not the only industry to have gratefully latched onto the the former Secretary of State’s famous phrase, “The unknown unknowns”. It’s a useful phrase to ponder if you’re responsible for planning or estimating anything. A recent slideshare by Danni Mannes on Agile Architecture pointed out to me that one should really consider the full matrix:

Known Not Known
Knowns Things we know, and we know we know them Things we know but don’t realise we know them; tacit knowledge that we take for granted. Become a problem if we are responsible, and fail, to communicate them to people who don’t know. Also a problem when we start work in a new context and don’t realise that what we ‘know’ is no longer valid, so they become unknown unknowns.
Unknowns Things we know that we don’t know. We can record the risk, and estimate a cost for investigation & discovery Things we don’t know that we don’t know. This is the quadrant most likely to shipwreck plans.

My personal takeaway from this is that I will try using this quadrant when listing risks. Just having a space for the possibility of unknown knowns & unknowns can be an impetus to do a little risk-storming & consultation, to help you discover the as-yet-unknowns.

P.S.

I’ve just read the brief and brilliant mcfunley.com/choose-boring-technology

Estimates and NoEstimates

We had a debate&discussion at XP-Man on NoEstimates for which I did some notes. Reading the NoEstimates stuff, I was most attracted to the sense of “Let’s not be satisfied with second rate” and of a thirst for continuous improvement.
I was left with the sense (possibly because I already believed it) that there are contexts in which NoEstimates works, and contexts in which it doesn’t. But I was very glad to be provoked to ask in each case, “What value if any is our estimate/planning effort adding?” and “Isn’t there a better way to deliver that value?”

What is an Estimate?

An estimate for a Project is (1) a list of things to work on; (2) a cost-range for those things; and (3) a list of risks, that is (3a) of Dependencies that 1&2 rely on, and (3b) of things that might cause significant change.

An estimate or plan for a sprint is (1) a list of things to work on, (2) a “cost” (eg story points) for those things and (3) a list of things we are uncertain about, or (4) need to get help with.

The value of a project estimate is to feed-in to (1) A go/no-go decision and (2) seeing things we want to see sooner rather than later (e.g. should we hire more people, do we need help from specific 3rd parties, is releasing in time for Christmas possible)

The value of a sprint estimate is, to see things we need to ask for in advance (ie external help or resources); to give everyone a sense of confidence about what we’re doing; to fail-faster, that is to see sooner what we can’t achieve.