On the use and abuse of Technology and its Management from the perspective of an academic at UCL specialising in Project Management, Systems Engineering and Space Science/Technology.

Monday, July 21, 2014

Long Tail and mending things

– or, how I saved myself £250 with 10 minutes soldering.

Everybody knows, I suppose, that modern products have built-in obsolescence, and are nigh-on impossible to repair, a least by users or street-level workshops. Not like in the Good Old Days, when grandad would take his lawn mower in for an annual fiddle, e.g. sharpening the blades or tensioning the chain, while he was busy filing the points on his old motor.

These days of course, everything's made of plastic (No sharpening. No chain) or is controlled by computer chips. Repair is not an economic option most of the time. It's cheaper to buy a new lawn mower than to pay someone to fix any of it, and most car owners never touch the internals. Even a proficient dealer will swap out an entire management system box rather than address an individual fault. A lot of these regressive decisions are not always cynical attempts to generate more sales, but instead often to do with the economics of service provision, based on the cost of human wages, not being able to keep up with machine-driven cost improvements in large-scale hardware production, which continues to deflate the real value of physical goods, even complex ones.

So, a pleasant experience of actually repairing something provides a counter-example, and perhaps shows that the road of progress isn't always headed in the wrong direction.

I've known for a while that if there enough potential repairers out there, there will be a viable niche for supporting tools and information. For example, because Apple sell a lot of nearly identical bits of kit, there's a very sophisticated website and supplies network for owners of slightly broken laptops, music players and the like (and not just the shiny things designed in California: iFixit have now started with other popular brands).  So the high-volume, high-class end of the self-repair market is pretty well organised, as you might expect.  I love the fact that this site can exist, thanks to the web, and that words like "Spudger" can be used for real things (it's a firm, plastic, blade-like tool used for cracking open "non-serviceable" seals in clipped-together cases).

At the low-frequency end of the popularity spectrum, a reasonably elderly family member's Panasonic DMR-EX75EB Freeview decoder with integrated HDD/DVD recorder stopped working after ~7 years' service. No digital channels (and no analogue channels either, after the grand UK switch-off : an example of IMPOSED obsolescence), although the rest of the box seemed fine. So he could no longer record things off the telly, nor use the DVD to distribute videos of outings to other people.

"Throw it away", I said, "get something new, it'll be cheap.".  But, looking at what's available now, it seemed that the market has moved along from recording DVDs anyway - on the assumption that one may as well use YouTube, Facebook, a memory card or some other means of sharing a video.  Only three similar boxes came up in Richer Sounds' lineup, and not that cheap. Coincidentally, all of these were from Panasonic, most other manufacturers seemingly now migrated to smart-TV type boxes, with internet connections for both input and output ("upload to YouTube in one click!").  All this talk of internet sharing was giving us both a headache (him trying to understand it, me explaining it), and I didn't fancy teaching him how to use the replacement box, especially with the sunk costs of supporting him through the Byzantine menus of the existing kit.

A bit of research found a couple of ideas, c/w with instructional videos, related to the observation that cheap power supply capacitors were prone to early failure, these being on a second-level sub-board housing the digital decoder section, and could therefore provide a repair solution. A search on eBay found a packet of caps for less than a price of a pint in London, and 10 minutes soldering was all it took to affect the repair.

So it looks like the Long Tail is filling up nicely even for services.

Wednesday, April 13, 2011

Capacity Optimisation

A brief rant on my other blog about trains, hence Capacity Optimisation.

As cycling swells in popularity, some decisions and assumptions made about 10 years ago on the design of train carriages now have noticeable effects. This sort of effect happens all the time, and it's frustratingly hard to see emergent properties like this, let alone model them.


Tuesday, September 14, 2010

Birth of a System - London Cycle Hire

People in London can't have failed to notice the introduction of a new transport system lately - the Cycle Hire scheme. At the time of writing it's roughly a month into operations. For the uninitiated, there are roughly 400 docking stations around town, each housing up to 20-30 bikes. Registered users present their dongles, unhook a bike and pedal off. At the other end, the bike is re-docked, and, in a database somewhere, a small charge is incurred. (More intro, Guardian, July 2010)

Some things I've noticed, and some questions.:

It's obviously a multi-element system: Bikes, Docks, Terminals, Back End Data, Billing, Logistics. It's additionally part of TfL's great big system-of-systems. It's got the Mayor's Office paw prints on it, but clearly has been in the works for years. It couldn't have happened, without Paris and a few other prototypes. Expect to see more in big and small cities round the world soon.

There are sprawling requirements everywhere, not completely understood. Here, for example, is a story about an odd feature of the database that caused the owners to back-pedal on a particular function, the multi-key account. Is the development cycle capable of adapting to new, or recently clarified, requirements? My guess is that, oops, the database contract has been and gone, and this feature will sink, rather than be implemented properly.

The initial users are enthusiastic, communicative, and alive to the possibilities it offers. Has this resource been tapped into? The forumites all want to talk to TfL and Serco (for it is they) but I suspect the drawbridge is up.

Data! There are plenty of feeds that allow the growth of applications (and, of course, Apps) to entertain and inform the users. Here, for example, is Oliver O'Brien's visualisation of real-time Dock status. (Oliver is a GIS nerd at UCL, but I don't otherwise know him). Here's another of his, showing daily stats, for example. Note how system availalbility is about capacity of both Bikes and Docks at each end of the prospective journey. Unlike a little French town (Lyon? Paris?), London's scheme is being used a lot, in two daily peaks, by edge-to-centre commuters. Machines and Holes are both at a premium at critical times. Has all this been modelled?

The contractors and operators aren't saying much for now, other than "we are working on the best way to do things". Do they mean us?

Originally Posted at Systems Engineering on KTN _connect.

Tuesday, July 20, 2010

Issues and Risks : philosophy of Present and Future

In Project Management, the concept of a Risk is fairly well established.

"An event, which, if it occurs, will have an effect on the Project's Objectives".

So if it's a harmful future event, we would note its likelihood, impact, and causes, and seek to manage it. By doing so, we reach into the future and handle it so that it does not impact the present in a way we would not wish.

Whereas an Issue is defined, at least in the APMP syllabus (PRINCE2 and PMI may differ on this definition) as
"a threat to the project objectives that cannot be resolved by the project manager. ... issues have already occurred and are therefore not uncertain".

APM Body of Knowledge, 5th Edition.

In teaching this, we fall into a sideline. Students ask: what about future events that are nearly certain. Aren't they also Issues? or Risks with very high probability? or just issues? Since escalation at the proper time is a key result of the Issue Management process, we should have a clear answer. We can reply by saying that the cause of the event was in the past, whereas the manifestation of the problem could be in the future. That satisfies some people, but not entirely. Then I saw this:

"Modern Western culture has absorbed the threefold Greco-Roman concept of time as "past" (that which has gone before), "present" (that which is), and "future" (that which will be). It is easy to associate these concepts with the three Norns Urdhr, Verdhandi, and Skuld. It is also incorrect. The Germanic time-sense is not threefold, but twofold: time is divided into "that-which-is," a concept encompassing everything that has ever happened - not as a linear progression, but as a unity of interwoven layers; and, "that-which-is-becoming," the active changing of the present as it grows from the patterns set in that-which-is. That-which-is is the Germanic "world," a word literally cognate to the Norse ver-├Âld, "age of a man." One will notice that even in modern English, there is no true future tense; the future can only be formed through the use of modal auxiliaries. For the Teutonic mind, all that has been is still immediate and alive; the present only exists as it has been shaped by the great mass of what is, and the future only as the patterns of that which is becoming now should shape in turn."
- By Kveldulf Gundarsson, Tuetonic Magic, p. 24.

Seen in Cloud Hands, Mike Garofolo's blog about TaiJi.

I can see the same dichotomy of viewing the future/potential in the way Risks ("that which is becoming") and Issues ("that which is") are treated. To put them in the Graeco-Roman mould of Future and Present seems to create difficulties which are avoided, to my mind, if we instead follow the Teutonic pattern. Ja?

Saturday, April 25, 2009

Misison statements and all that

I quite liked this post from Signal v Noise about crappy mission statements. Are they a US disease?

Some of my colleagues seem to think so. Furthermore, such drivel causes as much distress for the inmates of such organisations as for their supposed customers.

Thursday, December 04, 2008

Invention by Design, Petroski

Henry Petroski, Invention by Design

Henry Petroski has written a number of books that cluster around the craft and process of engineering. This one sets out to illustrate the inventive process of engineering design. I picked it up hoping to know more about innovation in other fields than my own.

In the ten or so case studies presented, the theme of the problem-as-impetus clearly emerges. Engineers, as critics of existing products, are driven to devise further inventive steps to reach toward a more excellent product. With some exceptions (the Boeing 777 case, which although probably the most contemporary, seemed to be lacking an undefinable quality of fidelity: does he really get what's going on there?), the cases revolve around the thoughts and craft of individuals. In some cases (the drinks can) their identities are obscure, whilst in others (the bridges of San Francisco) they spring from the pages dramatically. Exhibitions of patent documentation provides the bare bones, Henry P re-constructs the whole animal.

It's also clear that teams of engineers, or even distant collaborations, don't simply progress by cutting through an underlying bedrock of physical properties to get to the solution they seek. Rather, at each inventive stage, a higher order product, an improvement from the last, emerges from a mist. Thus we step from toggles to buttons, thence to what must have a been a nightmare of "automatic" clothes-tieing devices, to the zip as we know it. A series of hops then to the Ziplok bag, and yet another string of manoeuvres to Velcro.

But perversely, despite each invention begetting more invention, at the same time each enlargement of the scope and scale of the products seems to make it harder to analyse the next-generation design. Boeing's exponentially growing development budgets attests to this. Not all of the added complexity comes from within the product though, as there are network effects and social or legal changes concerning the use of the products that add further layers of requirement to each iteration.

The idea of resources as enablers, such as materials or tools, for certain types of design activity is also strongly exposed. He exemplifies this all through the book, pointing to CAD as a key technology for Boeing, standardisation for the Crystal Palace among many others. He seems to be too early to notice much use of computing in architecture though.

The chapter on buildings as systems shows how the problem complexity rises with each generation. Perhaps there is an inherent bias in these works, forgetting the industrialisation of innovation in mundane structures. The wonder of the local supermarket, reproduced thousands of times, as opposed to the award-seeking skyscrapers of the capital.

He uses terrorist attacks on the World Trade Center as an example of resilience of design. He refers of course to the 1993 bombs in the basement. What would he make of the later total failure of the designs in 2001, and was this indeed a failure of that particular building as a system, but a failure of a wider, un-designed system?