The big fat lie

I understand how queuing theory can help identify and reduce bottlenecks in processes and have used finger-charts and kanban-boards to do this for a while, but I still find calling this a “pull system” to be slightly disingenuous. All that’s happening is that more “stuff” is being pushed based on a trigger when certain buckets get too low. This reminds me of my annoyance with early technologies on the web that were touted as being “push” but were really just “repetitive-pull” (but not in a good way). I’ve never seen a software organization where the developers have said to the business or product people “we’ve got nothing to do, can you think up some new projects or features for us please?”.

My objection was always that even though looking at a software delivery process as a pull system was vaguely useful for debugging some process bottlenecks, it was a fundamentally incorrect way of characterizing what was really going on. It’s just not true that features or stories are pulled down through the analyze-develop-test-build-deploy-not-necessarily-in-that-order pipeline by the customer or even by a release manager; they are pushed down that pipe by a product or project manager and the pushing often requires a healthy dose of lubricant.

Pushing string

My moment of realization came in a discussion about process over-runs in the definition or analysis phase of a project. The team recognized that requirements weren’t being communicated clearly to the developers and were planning to spend longer on the analysis and definition phase to make the requirement documents longer and clearer. Their diagnosis was correct but their prescription for how to fix the problem would just exacerbate the pain. If people aren’t finding a document useful the answer isn’t to make the document longer!

This situation reminded me of the idea of pushing string. Attempting to push a single-page document is hard (it bends and wobbles), so adding more pages should increase the weight, or “thud-factor“, of the document making it easier to push … surely there’s nothing wrong with this logic!

Empowered to pull

The solution I suggested is to invert the process, empower the developers, and get them to pull the information they need. This fits with the general concept of “people-centered processes” that attracts me to lean and agile approaches (remember a bad process will beat a good person every time). If you allow your development teams to take responsibility for the product and features they’re building they will then pull the information they need at the times they need.

So it may still be a push system for features, but the flow of information is now driven by a pull system. This flip in direction allows all the benefits of just-in-time production and saves the problems associated with maintaining a large inventory. If you write all the details of a feature too far in advance it is certain highly likely that much of that work will be wasted since the details will change or the context will shift. Documents have a shelf-life just like any other organic product and that shelf-life is much shorter than you’d like to think.

The robot maker’s argument was that robots don’t have to be super intelligent to carry out some pretty useful, robotic, tasks. He was suggesting that there’s a blind-alley in robotic research premised on being able to map and track everything in your environment in order to move and interact effectively. His argument was that instead you just needed to be able to identify a goal to move towards and be able to avoid collisions. That is a much simpler goal than understanding your whole environment.

This leads to a different attitude to creating robots: have multiple robots, each good at doing one thing and then find a way to co-ordinate them. This is very much the Unix way as opposed to the Windows way.

From a feasibility and an affordability point of view this simplistic approach is much more achievable than the all singing all dancing uber computer often depicted in futuristic films. But his favored (and more philosophical) argument for this simplistic approach was that it would verge on the unethical to build a quasi-sentient being and then just ask it to fold your laundry every day. This is the Marvin-esque argument that the more human-like you make a robot the more you have to start affording it human-like rights.

Despite being interesting this line of argument instinctively felt wrong to most of us. Someone suggested the comparison with dogs, but it soon became clear that we feel animals have some level of rights too, whereas you don’t expect your computer or phone to complain when you keep asking it to check your email every few minutes. While there is clearly a quantitative difference between the rights of a human and a dog, there seems to be a qualitative difference between those of an animal and the rights we’d afford to a robot (however intelligent).

So I interjected and asked the simple question:

Does my hand have rights?

I ask my hand and my feet to do things all day (just like my computer) and I don’t expect them to complain or tell me they’re busy. This seemed to clarify the distinction for me that I’d been struggling to find.

The difference in my mind is that humans and other animals have their own goals that they are responsible for selecting (within some nature and nurture constrained boundaries). Robots (and hands and feet) on the other hand (API) are mere tools and don’t have separate goals or aspirations. This lack of goals and aspirations is the key differentiating factor that makes me feel comfortable not giving a robot freedom of speech / assembly / religion etc. I retain the absolute right to reformat my computer’s hard drive or swap it’s RAM without feeling any pangs of guilt.