Showing posts with label design. Show all posts
Showing posts with label design. Show all posts

Tuesday, 7 May 2019

don’t read before flying

Read the whole thing.  It makes for terrifying reading, if only because it’s going to happen again, and again, and again...

How the Boeing 737 Max Disaster Looks to a Software Developer

So Boeing produced a dynamically unstable airframe, the 737 Max. That is big strike No. 1. Boeing then tried to mask the 737’s dynamic instability with a software system. Big strike No. 2. Finally, the software relied on systems known for their propensity to fail (angle-of-attack indicators) and did not appear to include even rudimentary provisions to cross-check the outputs of the angle-of-attack sensor against other sensors, or even the other angle-of-attack sensor. Big strike No. 3.

I believe the relative ease—not to mention the lack of tangible cost—of software updates has created a cultural laziness within the software engineering community. Moreover, because more and more of the hardware that we create is monitored and controlled by software, that cultural laziness is now creeping into hardware engineering—like building airliners. Less thought is now given to getting a design correct and simple up front because it’s so easy to fix what you didn’t get right later.

It is likely that MCAS, originally added in the spirit of increasing safety, has now killed more people than it could have ever saved. It doesn’t need to be “fixed” with more complexity, more software. It needs to be removed altogether.



Monday, 14 January 2019

book review: A Burglar's Guide to the City

Geoff Manaugh.
A Burglar's Guide to the City.
Farrar, Straus and Giroux. 2016

There is a standard way to use a building: enter by the doors, look though the windows. There is a standard way to use a city: travel along the roads. Burglars don’t use buildings and cities in standard way: some enter buildings though windows, drop through hatches and ceilings, cut through walls; some move around cities through tunnels, either pre-existing or self-dug. Manaugh describes many of these alternate uses: some exceedingly clever, some just plain dumb. And he describes attempts to thwart the burglars, from law-enforcement helicopter patrols to high security panic rooms.

I have come across, in fiction if not in reality, many of the concepts here, but they are all engagingly presented. One aspect I found particularly intriguing was how law enforcement could get lost in certain kinds of locations. In one case it was helicopter pilots over a regular grid of streets, in another it was officers on the ground in a huge building with several identical parts. Both were lost in “a maze of twisty little passages, all alike”. We know the solution to this: drop landmarks. Law enforcement would like home owners to paint identifiers on their roofs. Alternatively, architects could design more varied structures: “a maze of twisty little passages, all different”, with the necessary landmarks already present.

Being able to think “sideways”, like a burglar, is a useful skill when designing any artefact: it will be misused, if not on purpose, then at least accidentally. Having these misuses catered for up front in the design is a plus. Having these literally concrete examples in mind can makes for more vivid analogies when trying to think sideways.






For all my book reviews, see my main website.

Sunday, 12 August 2018

book review: Living with Complexity

Donald A. Norman.
Living with Complexity.
MIT Press. 2011

It is interesting to watch Norman’s design philosophy evolve over a series of books. His 1988 classic The Psychology of Everyday Things argues for simplicity and naturalness in design. In his 2004 Emotional Design he is arguing for the consideration of the users’ aesthetic reaction to that design. And by 2007, in The Design of Future Things, he is focussing on the need for good communication between our ever-“smarter” technologies and us.

This 2011 book, Living with Complexity, admits that maybe simplicity and aesthetics isn’t the be-all and end-all of design. Our world, both natural and technological, is a complex place, and we want rich, complex interactions with it. Norman’s argument here is that good design should support that rich complexity, rather than making life harder by being unnecessarily complicated.
[p2] I use the word “complexity” to describe a state of the world. The word “complicated” describes a state of mind. The dictionary definition for “complexity” suggests things with many intricate and interrelated parts, which is just how I use the term. The definition for “complicated” includes as a secondary meaning “confusing,” which is what I am concerned with in my definition of that word.
There is a consequence of wanting rich complexity, however: it takes time to learn how to master it. We are (or should be) willing to put in the time when the reward is that richness.
[p30] Do we dislike the fact that learning to read and write, play musical instruments, and drive a car are all so complex? Not really. We don’t mind complexity when it seems appropriate. Yes, we truly dislike spending an hour learning some arcane, bizarre machinery. But we are willing to spend weeks or years learning other things, where the difficulties and complexity seem appropriate to the tasks
The issue is that we are often not willing to put in the time to learn complex tools. We seem to think everything should be easy to use (maybe because we have read some of Norman’s earlier books?) Norman argues for an even-handed approach: a willingness of designers to design well, removing complication, coupled with a willingness from users to put in the time to learn how to use the well-designed toolset. (Personally, I am willing to put in the time, but only in a staged manner: I want standard tasks to be simple and do-able without needing the full “10,000 hours” of mastery first, and only the richer, more sophisticated tasks to require a corresponding level of extra effort. That property, presumably, is part of the non-complicated design requirement.)

Norman offers a few guidelines on how to design well for complexity. The main one is to take a whole systems view: don’t improve just a single part of a malfunctioning system, rather, analyse the system to find where the real problem is, and redesign the whole of the “user experience” from beginning to end.
[p148] Never solve the problem the client has asked you to solve. Why? Because the client is usually responding to the symptoms. The first job of the designer, sometimes the hardest part of the entire task, is to discover what the underlying problem is, what problem really needs to be solved. We call this finding the root cause.
Of course, this is easier said than done in most cases. However, it is good to see an emphasis on treating a complex system as something that needs to be engaged with, not simplified out of existence.

Unfortunately, I found the quality of the book itself somewhat poor. The text feels rushed and not fully polished, with a lot of repetition, as if an idea was written down, then reworded, but the original not deleted. The quality of the photographs is very poor: often too small and too dark to fully appreciate the point being illustrated. And I have the hardback, not just a paperback with traditionally poorer quality pictures. It is also typeset in a sans serif font, which I personally find ugly and hard to read. Nevertheless, there is an interesting and worthwhile idea in here, about taking a systems design view in a necessarily complex world.




For all my book reviews, see my main website.

Wednesday, 25 October 2017

book review: What Works

Iris Bohnet.
What Works: gender equality by design.
Harvard University Press. 2016

We hear a lot about people trying to fix gender equality issues with little success, or even denying there is a problem. This book provides evidence that there is indeed a problem, why many existing approaches to tackling it don’t work, and lays out proven ways to ameliorate it.

I’m taking it as given that there is a problem, but if you disagree, Bohnet provides plenty of evidence of its existence. The problem is not restricted to the misogynists actively discriminating; it is also due to the unconscious biasses we all have, sabotaging our best efforts. But unconscious bias training has very little effect. And stereotypes are hard to overcome: if women aren’t appointed to certain positions because of the stereotype that they aren’t appropriate in those positions, then there will never be any evidence to overcome the stereotype. So what should we do?

The answer Bohnet advocates is behavioural design: changing not our innermost biasses, but nudging what we do in the right direction. After all, a bias that is never acted on doesn’t really matter. So Bohnet lays out a series of design changes – to our hiring and promotion processes, to our team building, to our norms, and more – to make it easier to act in a more inclusive way. These can be implemented piecemeal using an unfreeze (the old behaviours) – change (to the new behaviours) – refreeze (stick with the new behaviours) process. (This reminded me somewhat of Arnold’s microresolution approach; the changes here are “micro” relative to the business scale.)

Examples of behavioural design include: recruit staff in batches, rather than one at a time, to reduce the temptation to go for the standard option, and to allow for more diverse choices; interview one-on-one rather than in panels, and aggregate the individual interviewers’ inderpendent scores, to avoid groupthink. Quotas can help level the playing field; to get round the perception that the “beneficiaries” of the quota are under-qualified, first choose a long-list of candidates based on quality, and only then use the quota to increase diversity; everyone eventually chosen has passed the same quality threshold.

Some of the evidence shows possibly counter-intuitive effects. For example, having a “token” minority can backfire: the way our biassed brains work means that singletons will typically be judged by their group stereotype, not by their individual qualities. Including more than one person from the particular group allows each to be seen and judged more as an individual, rather than just as a representative of their class. This is the “critical mass” effect: a minority shouldn’t be present as less than one third, or three people, in total. This is an interesting approach. It implies that if you have a class of say 40 students, 30 men and 10 women, to be partitioned into teams of four, then it is much better to have five teams with two men and two women, and five teams all men, than to have 10 teams of three men and one woman.

There are many more relatively simple ideas for change here, from wording in job adverts to de-risking applications, from negotiation processes to stereotype threats, from the importance of role models to implementing transparent processes. And Bohnet is a strong advocate for the use of data to determine the presence and shape of the problem, and the using controlled experiments to determine the effectiveness of the interventions.

I have just summarised parts of the advice: Bohnet provides the rationale and the evidence. If you are serious about improving gender equality, and equality for other under-represented groups, then this is the book for you.




For all my book reviews, see my main website.

Friday, 8 September 2017

ECAL 2017, Friday

The final day of the European Conference of Artificial Life, in Lyon; actually only half a day, to allow people to travel home.

The keynote presentation today was Sabine Hauert talking on Swarm engineering across scales: From robots to nanomedicine.  She started off with a description of her work on swarms of flocking robots, and how to control their behaviour without GPS absolute position, only short range wifi and a compass heading, and where the fixed-wing flyers have restricted manoeuvrability.  But these are small swarms: 10s of devices.  At the other end of the scale is use of small particles in nanomedicine, where the numbers are more like 10^13, 12 orders of magnitude larger, and the controlability is even less, having to rely mostly on diffusion and similar processes.  Most of the “programming” goes into the design of the “body” of these “brainless” particles, adjusting parameters such as size, shape, charge, material, and surface decoration with molecules that can interact with cell receptors.  Once the nanoparticles have “leaked” out of the bloodstream into the tissue, they might be activated by light or heat.  The aim is to come up with generalisable design guidelines.  One approach to searching the vast design space is to use a game to crowd-source workable designs for different scenarios.

After coffee was the final technical session of the conference.  I went to the Artificial chemistries and models of cellular dynamics 2 session.  In Transparency Of Execution Using Epigenetic Networks we heard about a form of neural network that can modify its topology during execution.  A Dynamic Model of the Phosphate Response System with Synthetic Promoters in Escherichia coli was a quite detailed simulation of a particular pathway.  I missed the last presentation, as I needed to get back and get ready for the closing session, which included some announcements about ISAL and the Artificial Life journal (I plugged the review article section), and then huge thanks to everyone involved in organising and running this splendid conference.

Then is was a picnic lunch, and saying our goodbyes (until next year?), and travelling home, our brains full of lots of wonderful new stuff.

Travel involved a tram to the train station, the express tram to the airport, a lot of waiting around (I had gone a bit early, as I had heard there were delays at passport control at Lyon; I needn’t have bothered, as they didn’t open passport control until just before the flight was scheduled), an easyJet flight to Gatwick, a train to St Pancras, a walk across the road to Kings Cross, another train, then finally a taxi, arriving home at 11pm.  One book read on the way out; another read on the way home.


Sunday, 11 January 2015

book review: Agile!

Bertrand Meyer.
Agile!: the good, the hype and the ugly.
Springer. 2014


I’ve been a fan of aspects of Agile Programming ever since I first read about it. In particular the incremental style works very well in building software to support scientific research, where you really don’t know what you need to do next until you have run the prior experiments and come up with the next hypotheses; the discipline of YAGNI (“You ain’t gonna need it”) can save a lot of time and effort here. The “always have a working system” (continuous integration) part also works well for student projects, with their rigidly time-boxed hand-in dates. However, I also have a background in formal methods, so some of the more seemingly heretical and potentially “hacky” bits of the process do raise an eyebrow.

That’s where Agile! comes in. Bertrand Meyer is in the “strong software engineering” camp, strong on specification and design, and the inventor of “design by contract” in the 1980s, an approach of which I’m also a fan. What is he going to say about this new approach?

Unsurprisingly, he thinks some of it is bad; very bad. More surprisingly, possibly, he thinks some of it is not just good, but even “brilliant” (his term). He goes through the various components of the various Agile approaches, describing and critiquing them. He puts most emphasis on Scrum, with which he is most familiar (even being a certified Scrum Master), but also covers Crystal, XP, and Lean.

In summary, the ugly includes the lack of upfront specification and design (even allowing for the fact it will change later) and specifically user stories as the basis for requirements and test-driven development as the basis for design; the hype includes pair programming and collective code ownership; the good includes refactoring; the brilliant includes iterative development, continuous integration, and test first development (associating a test with every piece of functionality).

His argument for up-front specification and design includes the need for finding good abstractions, which will not automatically emerge from a test-code-refactor cycle. A specification is more abstract than a test suite, because it covers all the cases (thereby removing the problem of induction, or inducing the general from the specific). Similarly, he argues that user stories are to requirements what test cases are to specifications, including the same problems of lack of generality and completeness. We presumably need another aphorism to complement Dijsktra’s famous observation that testing can show the presence of bugs, but never their absence. Maybe it should be something like user stories can show the inclusion of functionality, but never its omission.

My only peeve about the book is some of the typography. Occasional paragraphs that are “asides” are set in a smaller font size. Every time, I initially parsed these as quotations, and had to backtrack. Notwithstanding this minor point, Agile! is an excellent thoughtful critique of Agile methods. Although Meyer introduces and describes all the concepts he critiques, I don’t think it is a stand-alone text, as those descriptions are somewhat brief. However, is should be required reading for anyone using, or about to use, an Agile approach.

At 170pp, it is a fast, if dense, read. I laughed out loud on several occasions. For example, he comments on the picture accompanying the agile manifeso:
p1. The sight of a half-dozen middle-aged, jeans-clad, potbellied gentlemen turning their generous behinds to us appears to have provided the decisive sex appeal. Personally, had I wanted to convey the suggestion of agility, I might have turned to something like the cover photograph of this book — which only demonstrates how out of tune I am with the times, since the above picture was successful beyond anyone’s dreams.



For all my book reviews, see my main website.

Wednesday, 19 November 2014

Design in the Park

I was at a two day workshop on Design: Shape & Structure in Leeds this week.  Part of the event involved technical conversations in small groups as we walked around the Yorkshire Sculpture Park.

Some of the sculpture I liked very much:

Ursula von Rydingsvard
Some was fun:

Marialuisa Tadei, Octopus, 2011

Some I thought was a bit pretentious:

Richard Long, Red Slate Line, 1986 (part of “walking as art”)

And a lot more I didn’t photograph.

At one point I was reminded of the amazing abilities of the human eye.  The two photographs below are of the exact same scene (as you can see from the shape of the treetops), one focused on the ground, one on the sky:

14:30 GMT, and the sun is already that low…
The shot on the left has a greatly over-exposed sky; the one on the right has a very underexposed foreground.  Yet to my eye at the time, the foreground appeared as in the shot on the left, whilst the sky looked like the one on the right (in fact, it was the glorious sunbeams that made me take the shot).  I am sure I could have got a better photo with something a bit more sophisticated than my phone-camera, of course.

As we were leaving, I spotted this very square tree, looking almost like a sculpture itself:

what growth rules result in this shape?
As a way of getting to know the research interests of the other members of the workshop, of getting fresh air, and of getting muddy shoes, I can highly recommend this walk-and-talk approach.

Sunday, 2 November 2014

who’s idea is it anyway?

After solving our recent book storage problem, we decided to tackle the lack of storage in the bedroom.  We had a wall with a couple of old bookshelves, a tatty old chest of drawers, and a small ottoman, with everything piled higgledy-piggledy.  We decided to to replace these with some proper wardrobes.

Googling around, we came across something that looked plausible, from Ikea.  Not being previous Ikea-ites, this required a bit more research before splashing out.  I was a bit dubious, frankly, so one evening after work I drove over to the Leeds Ikea, and wandered the maze of twisty little caverns, snapping photos of the installations we had identified via the web.  We looked these over at the weekend, and decided they seemed fine.

There’s also a spiffy little online design tool, so we played around with various options for quite some time, before deciding on a configuration.  This was great, as we ended up with something quite different from our original ideas.  We ordered it, paid an extra £35 for delivery, and sat back to wait.

that’s a lot of flat-pack
Six carcasses, 16 drawers, 8 baskets, and 22 shelves take up surprising little space when packed flat.

The first weekend we tackled construction, we managed to erect two of the carcasses.

two down, four to go
The first one took us two hours to build.  The instructions are all pictorial, and quite clear (although do require careful peering in places to see orientations), but we went slowly at first to ensure no mistakes.  By the time we built the final carcass, a couple of weeks later, we were down to less than half an hour.

ready for the shelves (the ice cream cartons are to hold the various fixings)
Once we had connected the carcasses together, and attached them to the wall, they were rock steady.  All that remained was installing the shelves and drawers.

the finished construction, awaiting content
The drawers were the most complicated to assemble, so again we started slowly and carefully, but by the 16th, we were fairly ripping along.

I was very impressed with the build quality.  Sure, the “wood” is laminate over fibreboard, but the fixings are solid, and everything fits together snugly, solidly, and firmly.

Given the number of carcasses, shelves, and drawers, we managed some small process improvements as we went.  One of these was rather peculiar.  On the bottom of each drawer are a couple of plastic clips that hold the drawer on the runners.  The instructions say to install the clip after the drawer is placed on the runners; this is quite fiddly to do.  As we were assembling the drawers for the second small carcass, Charles said: “let’s put the plastic bits in before we install the drawers”.  So I took the drawer we’d just assembled, turned it over, and pushed the clips in place.  “Oh, I meant the plastic bits for the shelves, but that looks a good idea.”  It was: it made the drawers much easier to install.

So, it was a good idea, but who actually had it?  I was just following what I thought Charles had suggested; he was actually suggesting something quite different!



Friday, 26 September 2014

book review: Best Practices of Spell Design

Jeremy Kubica.
Best Practices of Spell Design: a computational fairy tale. 
CreateSpace. 2013

This book illustrates various good practices of software design through a sequence of vignettes set in a fantasy world of wizards, where spells (and bakery recipes, and accountancy) have a distinctly computational nature.

I enjoyed this, but found nothing particularly deep here. I realise that I am not the right audience for the book, since I have come across (and try to use!) all the techniques illustrated, from comments and named constants to problem decomposition and test driven requirements.

However, I am not entirely sure who the right audience might be, given the wide range of subjects covered. Apprentice programmers will not get some of the later material; those more experienced should already know the earlier. Maybe it is for those self-taught (rather than apprenticed) hackers, who have never come across these concepts? If so, this is a fun, and memorable, way to illustrate good practice.


For all my book reviews, see my main website.

Sunday, 9 March 2014

book review: Tempo

Venkatesh Rao.
Tempo: timing, tactics and strategy in narrative-driven decision-making.
Lightning Source. 2011

Life is a verb, not a noun.
— Charlotte Perkins Gilman
Despite Gilman’s aphorism, people seem much more able to think in terms of things rather than actions, stuff rather than change, objects rather than processes. This may be because, as Mark Bickhard points out, we have a substance metaphysics, but no acceptable process metaphysics. Rao’s slim book (150 pages in total) goes some of the way to providing the latter for our social environment.

Rao starts from the idea of process, of a sequence of events, and goes from there, to bring in the concept of time. His time is not merely an ordering of events, but is a measure of the rate, of the tempo, of those events. Understanding the tempo of the various processes, and how these interact, and interweave, is the basis of his discussion of decision making, from individual cooking to multi-person businesses.

Understanding the dynamics of the decision-making process exposes various phenomena that can be part of the process. Rao identifies fait accompli, brinkmanship, procrastination, second-guessing, passive aggression, time-outs, defaulting, and building mindshare, among others.

We constantly need to make decisions, and those decisions need to be situated in the current context. Context switching includes gaining situational awareness (grokking where things are and what they are doing, now and in the near future) in the new context. Situational awareness crucially includes awareness of the situation’s tempo.
p115. The major claim in this book is that tempo can be used to modulate enactments that move along too quickly to manage one micro decision at a time.
Once you have an awareness of the tempo, you can modulate it to improve your performance, either in competition, or cooperation, with others in the environment.
p118. The primary effect of operating at a faster tempo is that you can maneuver inside the decision cycle of your opponent, disrupting his or her enactment …
    This style is obviously effective in adversarial settings, but it is equally effective in cooperative settings …. The alert waiters at upscale restaurants, fulfilling your needs before you even recognize them, are a good example.
The situations we encounter are not arbitrary. They may have a greater or lesser degree of legibility to us, and we modulate our environment to control situations and their legibility. Rao explains how we do this. We comprehend the world through mental models, and we organise the world to externalise these models. This organisation, this modulation of our environment helps us improve our efficiency, our ability to perform.
p127. To externalize a mental model is to arrange our physical environment to serve our intentions more efficiently. In cognitive psychology, this idea is called distributed cognition.
The full process of organisation is a combination of objective and deliberative design and of participatory dance dependent on situational awareness and tempo; how much of each component we use depends on circumstance and preference.

Different styles of decision making follow different patterns; Rao identifies reactive, deliberative, opportunistic, and procedural. For example, a procedural, or bureaucratic, style has the environment organised by another, so that you can follow a codified process without necessarily understanding it, yet still achieve the desired outcome.
Civilisation advances by extending the number of important operations which we can perform without thinking about them.
— Alfred North Whitehead
Following such an opaque procedure can be very efficient, because you do not need to think so deeply, but if the context deviates from that assumed by the organiser, you cannot then readily modify what you do not understand.

On the other hand, our personal, efficient organisation of our environment has meaning to us. This meaning may be legible to others, or it may not. If we wish to organise in concert with others, we need to be legible to them, but this might impact our own efficiency. Bosses who demand tidy desks are prioritising their own need for legibility, for control, over their staff’s efficient meaningful organisation.

Central planners can have the same desire for control, but this can kill the very thing they are trying to create.
p133. … central planners begin by poorly internalizing a rich, emergent collectively externalized mental model (such as the structure of an old city). They proceed inevitably to failure when they attempt to replace it with the externalization of their own impoverished mental models, constructed largely out of primitive platonic ideals, a case of design destroying dance.
Nouns and verbs tend to focus on single specific things. Rao lifts these concepts into the environment, as fields and flows.
p138. Fields are arrangements of the physical environment. Flows are the behaviors that result when humans interact with a field. Flows are the observable parts of others’ enactments.
Rao is not concerned with a general model of all physical reality here, but with an approach to situated decision making, of people in social environments.
p139. For a given individual, the environmental field … combines with the other group members in the field at the same time, to create a social field. When there is little momentum or meaning in the primary environmental field, the dynamics of the social field start to dominate. An environmental field that is deliberately designed to catalyze complex social behaviors generally contains one or more social objects…. Chairs and tables are among the simplest social objects.
Unlike the models and processes imposed by central planners and rigid bureaucrats, Rao advocates a balance between the aspects of design and dance.
p141. Artistic approaches to field-flow complexes exploit the natural chemistry among mental models in richer ways. The key to such approaches is a tasteful blending of preparatory design and participatory dance. Successful field-flow complexes can neither be designed nor danced into existence. They must be orchestrated. A conductor or choreographer, rather than a pure designer or dancer, is necessary.
The metaphor of conductor or choreographer, rather than the extremes of rigid pre-programmed design, or of completely fluid and potentially chaotic dance, is interesting. Denis Nobel uses a similar metaphor to explain biology. It seems to be a metaphor well-suited to a variety of complex systems.

Complex systems comprise a collection of agents interacting in and with a complex environment. For a single agent, its environment comprises not only the organised spaces, but the other agents, too. In Rao’s model, the agents are people making their context-dependent situated decisions.
p143. Groups cannot be realistically studied unless you take into account the effects of the field-flow complexes that they inhabit. This is a natural consequence of narrative rationality: you can only understand a group with reference to the specific narrative within which it is situated.
That is, the same group of people in a different environment, or even in the same physical environment in a different context, will behave differently. This should not be at all surprising, but the environment and context are often neglected in complex systems analysis in order to simplify the problem; just think of in vitro versus in vivo experiments, or many experiments performed in psychology labs.

Rao demonstrates how a consideration of tempo, situation and context, and of patterns of decision making, can illuminate many more patterns than the standard procedural bureaucratic one. Moreover, these other patterns and metaphors have distinctly different flavours, especially when applied to changing an organisation.
p144. Where change in the machine metaphor is a process of stepwise re-engineering, in the other, more organic metaphors, change is a process of generative growth, ontogeny and self-organization.
This book nicely complements a lot of books trying to apply complexity theory to organisations. Here Rao focuses on complex human systems, involved in descion making, aspects often missing from the more theoretical models of complex systems exploited by the other approaches.

This deserves rereading. Some of the earlier discussions, which can have a slightly hippy-Zen flavour (despite many examples being from military command and control) take on more meaning in light of the later application. Recommended.




For all my book reviews, see my main website.