Jean Prouvé: The poetics of the technical object

I confess I had never heard of Prouvé before I came across this exhibition at London's Design Museum but the title grabbed me. If I had have known how interesting and relevant Prouvé was I would not have left it to the last minute to go. I think he's not better known outside of France because he mainly worked on municipal projects.

He never formally trained as an architect; so although he did work on the design of buildings, his is not the name which tends to be associated with them. His most iconic designs are chairs. But these are chairs for university halls of residence, works canteens and classrooms, not the sort of chairs which grace Notting Hill living rooms.

Although he came from an artistic background Prouvé started out as an artisanal blacksmith in 1919. He quickly moved from wrought ironwork into steel and aluminium, but he always remained rooted in the practice of working with materials. He designed through trials and testing of concepts.

"...one should not sketch out utopian projects, because evolution can only result from practical experience."

This commitment to evolution is demonstrated by a display of Standard Chairs, variations on a theme produced by Prouvé's workshop over the course of two decades. The basic shape and configuration of Chair No.305 is not markedly different from Chair No.4. There are minor tweaks, and there are variations in material: wood, steel or aluminium, plain or lacquered. The biggest adaptation was the collapsible Standard Chair.

As an artisan and then a factory owner he understood the properties of wood and metal and their appropriate usages. Designers and architects more driven by the need to appear avant garde tended to get carried away with the thrill of new materials and looking modern. Prouvé appreciated that good design had to come from functional success: no matter how striking it looks, a chair is no good if it is not comfortable to sit in. An example is the Solvay table, which is made of wood bolted together with lacquered steel. The engineering of the table is not hidden, it is part of the aesthetic, but neither is it fetishised.

Prouvé was a early adopter of the concept of design patterns. He assembled a dictionary of structures which could be reused in different situations and scales. The crutch - a asymmetric Y shape - which supports the roof of the Pump House at Evian re-appears in the design of an armchair. He devised a roof made of single curved pieces of steel. These shells were light enough for two men to slot them together. At a larger scale this shape could be rested on the ground to form vaulted halls. One favourite shape, a elongated pentagon, appears repeatedly in his work: as the back legs of the Standard Chair, as the legs of various tables, in the cross-section of a table top, even as the handles of a sideboard.

I tend to be wary of attempts to draw parallels between our industry and branches of engineering or architecture, as these strike me as attempts to lend software development a spurious sense of discipline. Just calling it "software engineering" does not make writing a program as rigourous an activity as building a motorway flyover. However, with his commitment to iteration, re-use, modification and adaptation, and his championing of practice over theory it is hard not to regard Jean Prouvé as the Godfather of Extreme Programming.

There's more

The other exhibition at the Design Museum featured lots of modern work. One of the most striking exhibits was a chair "sketched" by a Japanese design house called FRONT. Their designers have developed a mechanism for designing furniture through motion capture and then rendering the designs using extruded plastic. Unlike Prouvé's work you probably wouldn't want to sit on the chair or rest a cup of coffee on the table but the process is fascinating to watch.

Code quality metrics

Whenever two or three developers gather together they will argue over the best tool for editing code. Once they've chewed the spearmint out of that they will commence a heated discussion on ways to measure code quality. But I think this cartoon by Thom Holwerda pretty much nails it.

Who needs SQL injection?

I - probably like many of you - thought the prevention of SQL injection (the passing of additional SQL statements through the parameters of dynamic SQL calls) was the low hanging fruit of web app security. Not at all. This latest post from The Daily WTF really takes database (in)security to another level.

In praise of the Checklist

I love reading The New Yorker magazine. Partly the it is sheer expanse of the articles, which are measured in pages rather than paragraphs. But also it's the breadth of the coverage. Okay, so I could do without the profiles of baseball coaches but pretty much every article is worth reading. Unfortunately I lack the time to read each issue, so these days I buy it when I want to pretend I am still a leisured (and cultured) person.

I have just got around to reading last week's issue. It contained a fascinating piece by Atul Gawande on the use of checklists in intensive care units. ICU staff deal with an very complicated piece of machinery (i.e. us) when it's in an extremely precarious state (hence the need for intensive care). There are thousands of different ICU procedures. Each procedure consists of multiple steps; if somebody misses or botches a step there are often terminal consequences for the patient. Furthermore each condition requires a unique combination of ICU procedures, staff and equipment. Patients in intensive care frequently die there.

In his piece Gawande talks about the efforts of a critical-care specialist named Peter Pronovost to improve survival rates by the simple expedient of checklists for a handful of common yet critical procedures. It is astonishing how such a simple thing can make such a profound difference:

"Pronovost and his colleagues monitored what happened for a year afterward. The results were so dramatic that they weren’t sure whether to believe them: the ten-day line-infection rate went from eleven per cent to zero. So they followed patients for fifteen more months. Only two line infections occurred during the entire period. They calculated that, in this one hospital, the checklist had prevented forty-three infections and eight deaths, and saved two million dollars in costs."

Less surprising but more depressing is the difficulty Pronovost experienced in persuading highly-qualified doctors to bother themselves with yet more form-filling.

Most of us in IT have similarly mundane-yet-complicated procedures. Of course, hardly any of our procedures are literally life-or-death, but there are usually penalties for getting them wrong (even if it's only digging out the manuals to refresh our memories on Flashback Database). Checklists are good because they prompt us to go through each step of a prccedure. And because the machinery we deal with is a lot more tractable than the human body we can often automate our checklists into stored procedures, shell scripts or workflow processes.

Gawande's article reminded me of a couple of things I do on an infrequent but regular basis which would benefit from being documented in a checklist. But it's also a fine and moving piece of writing and worth reading in its own right.

Simplicity is in the eye of the beholder

Laurent has posted a particularly succinct method for doing bitwise aggregations on his blog. I don't know what practical use it is, but that's another matter. What I liked was his cheeky sign-off, "It is that easy!". Which reminded me of a story from years ago, when I was still in the Ministry of Defence

I was sent on a CORAL 66 course. CORAL was a 3GL intended for real-time programming and it combined keywords in English with some very low level functionality, including the ability to flip individual bits. As a COBOL bunny with a History degree this was this first time I'd ever had to wrangle bitmasks and it made my brain hurt. I wasn't lucky enough to be sent on the subsequent advanced course (five weeks long, those were the days!) but these who did got to build either a missile guidance system or a safety system for a nuclear power station in their exercises. Even on the beginners' course the exercises were fairly hard going.

One involved translating Morse code into letters. I went for a data-intensive solution. I wrote an array with all the letters in the Morse alphabet. This was hard work but the actual processing was quite simple: start in the middle of the array and shift the index left or right depending upon whether the current character is a dot or a dash, halving the offset each time. When there's no further input the index points to the transmitted letter.

There was a very bright chap on the course. We often talk about junior programmers, but this guy was definitely junior, because he was a lance corporal and so everybody else on the course outranked him. Even me: as a civvy I had a notional rank of lieutenant. Most of the trainers were officers but there was a sergeant whose job it was to answer the questions of the non-comm students (they weren't allowed to ask officers questions or indeed initiate any conversation).

Anyway, this corporal's solution consist of a single very dense recursive algorithm which somehow spat out the right answer. However, his code contained just the one comment: "This algorithm is easy to understand so no further explanation is necessary." The trainers didn't understand his algorithm and he knew they wouldn't understand it and they knew that was why he had put the comment in. So they marked him down, for insubordination.

My PL/SQL Coding Standards

As I mentioned recently a long-running trolling thread in the OTN forum has recently taken a new twist, by reviving the PL/SQL Coding Standards meme. Alas I was wrong in my prediction that the OTN moderators would soon kill the thread. Not only is it still going but the evil genius behind it is still going, and regularly changing their handle. Currently it is my turn to be impersonated.

In order to justify my assertion in that thread I have decided to publish my damn fine standards. So here they are.

---

APC's Damn Fine PL/SQL Coding Standards

1. Your code must implement the requirements correctly and completely.
   
2. Your code must have a suite of unit and integration tests (preferably automated) to prove it implements the requirements correctly and completely.
   
3. Your code must implement the requirements as efficiently and peformantly as possible.
   

---

Is that it?

These standards have much to recommend them. They are easy to read. They won't need revision whenever there's a new version of PL/SQL. And they focus on what is really important in code: correct functionality. Of course things such as layout and naming of variables are important, I'm not saying they're not. But a PL/SQL procedure can be neatly laid out, rigourously capitalised and thoroughly commented and yet be full of bugs. In my experience, most coding standards tend to document in tedious detail the things which are easy to standardise - use of upper and lower case, line indentation, etc - rather than the things which actually matter.

Also the strictures of codings standards are rarely revised. I still get handed coding standards which say things like "Always use explicit cursors". So either these standards were written ten years ago or the author has not coded any PL/SQL in the last ten years or the author should be shot. Whichever it is, if the standards document contains such canards, why should anybody pay it the slightest attention?

I intend to expand upon some of these points in future posts. If you want a more regular set of PL/SQL Coding Standards then you should check out the redoubtable William Robertson's site. Alternatively, invest in a copy of Oracle PL/SQL Best Practices by Steven Feuerstein (Whom God Preserve). I don't agree with everything that Steven writes but I firmly believe that if every PL/SQL coder in the world followed these guidelines the overall quality of the global PL/SQL codebase would increase by several orders of magnitude.

Update

The troll has now reverted to an anonymous userNNNNNN handle and restored the original text. Obviously even they have got tired of the joke. Or been stricken by conscience.

Meeting William Gibson

Not many novelists bring out the fanboy in me, but Gibson is one of them. Neuromancer was, literally, the book that changed my life. It's why I decided to become a computer programmer.

In the summer of 1986 I was a disillusioned History student about to become a disillusioned History graduate. I had finished my finals, I had no job lined up and I had no idea what I wanted to do with my life. It was in this state of aimlessness that - inspired by an article by William Leith in the NME - I purchased Neuromancer. It was the first pure SF novel I had read in years and it was completely gripping. I can still recall the adrenal rush of the last few chapters, racing through them just to discover how the story ended.

I had read SF as an adolescent but discovering JG Ballard had derailed me: nothing else in the genre could quite match the intensity of his prose. At university I had read mainly non-fiction: there was so much reality to discover, it seemed pointless to read to stuff people had made up. When I was studying European heresy my tutor John Critchley advised me to read Umberto Eco's The Name of the Rose (I was chuffed to explain to him that the blind librarian Jorge of Burgos was a reference to Jorge Luis Borges, because that joke had passed him by). I also read Mishima because I did courses on both medieval and modern Japan, and he seemed appropriate. For light relief I read Italo Calvino's short stories and the Blandings novels of P.G.Wodehouse.

I realise that list probably makes me sound like an insufferable prick. But then I probably was an insufferable prick at university, so that's fair.

I'm not going to do a review here. I presume everybody who reads blogs has read Neuromancer. If that's not the case stop reading this right now and go read it. Like most SF it has dated but not as badly as some. Few SF authors have changed the world. My quasi-namesake Arthur C Clarke did, with his invention of the geosynchronous satellite, but largely his vision has not been realised. No lunar explorers have disinterred mysterious black slabs because there are no bases on the moon. Heck, nobody's even been to the moon for over thirty years. Whereas it's a measure of the impact Gibson's writing has had on the world that he has stopped writing SF and moved into regular fiction without any meaningful change of tone or subject matter. (I guess Bill Gates, Steve Jobs, Michael Dell, Larry Ellison and others have also had something to do with it).

Gibson's insight was to take the glamour which traditionally attached to spaceships and astronauts and transfer it to computers and programmers, who were - it's fair to say - not glamourous. At Exeter the Comp Sci students were pimply-faced youths in brown and beige, as boring as accountants. In fact, more boring: at least there were some girls amongst the accountancy students. Neuromancer changed that image by making computers cool, sexy and edgy. Which is why it has had such a profound effect on modern life. All over the world, pimply-faced youths in brown and beige set about immanentising a world in which computers - and by extension the people who worked with them - were cool sexy and edgy.

Neuromancer was Gibson's first novel. In 1986 it was a bit frustrating to discover that there wasn't anything else to read by him. I just had to wait until Count Zero came out. On the other hand it does mean that every few years there is a new novel to look forward to.

So today I joined the line of people to buy a signed copy of Gibson's new novel, Spook Country, at Forbidden Planet. I told him I was grateful to him for writing Neuromancer because it had directed me into a career in software development. His face crinkled with recognition. "Oh you're one of those guys," he said. Yep, I'm one of those guys.

Software Contract Law

I hesitate to describe an article on computer law, especially one about the enforcement of software contracts, as "interesting" but there is no doubt that this is an important area for all of us. Of course, one side applies primarily to product vendors and consulting developers but we are all of us on the customer side of the fence. So everybody ought to read Cem Kaner's piece on an American Law Institute initiative to write a new Principles of the Law of Software Contracts.

He has also published his presentation to the Conference of the Association for Software Testing on this topic. This contains lots of insights into the evaluation of licensing law but it does also contain screens full of legal small print (literally).

The focus of Cem's analysis is on the enforcement of warranties. In particular, the proposals would make software suppliers liable for damages suffered by their customers as a result of bugs which were known to the supplier but not disclosed to the customer. You can see why lawyers might be keen on this proposal: Have you suffered from Blue Screen Of Death? Turn those bugs into £££! Calls Claims Direct now!

On the other hand, certain things would become freer. For instance, under a "standard-form transaction" (i.e. one used by the general public, as opposed to an individually negotiated one) companies such as Oracle would be unable to prevent the publication of the unauthorised benchmarks. There might also be implications for certain aspects of the OTN licence, such as the recently discussed confusion over whether we can use a database downloaded from OTN at home for instructional purposes.

MiniSPA 2007: Better than working

I took yesterday off to attend the 2007 MiniSPA conference. This was a greatest hits compilation of sessions from this year's SPA conference. I almost typed "presentation" but relatively few sessions actually consist of a speaker at the front of the room reading PowerPoint slides to a passive audience. The SPA principles value interactivity and participation. Instead there is a variety of sessions types, most of which involve the audience in some way; tutorials, case studies, workshops, panel discussions, simulations and goldfish bowls. So agenda decisions have another dimension ("how much thinking do I feel like doing?").

The opening session was a think tank. We were divided into teams and each team had to complete the following sentence in no more than ten words:

"Hey, I hear your business depends on delivering software. Well the most important thing about software development is ..."

Each team had to agree on its own phrase; then everybody voted on the phrase they liked the best. The secret of these things is to come up with something snappy and comprehensible. One team came up with a suggestion which had three clauses and used bullet points. That is a dead loss. You can't buttonhole somebody in the corridor and then ask them to wait whilst you boot your laptop and fire up PowerPoint. Here are a few of the final sentences.

• If it's any good, software lasts a long time.
  
• It encodes people's knowledge of the business to provide value.
  
• Get the best project manager you can.
  
• It's about people not computers.
  

That last slogan was the one for which most people voted, thus proving that people repsond to the clarity and focus which abstraction provides.

Designing Collaborative Workspaces

Mike Hunt (Mandu Ltd) led this workshop. Working in teams we had to build models of workspaces out of art card, Lego, Plasticine, Playmobil and various other craft materials. In the first round we had to build a bad working environment, then in the second round we had to build a good workspace. Although each team had a different scenario, the various models had certain common traits. The bad environments all tended to be cramped with people working in fenced-off isolation and with inadequate space for intra-team communication. Fans and other symptoms of poor air-condition featured a lot. The good workspaces were all spacious, with different rooms for different work modes. Bespoke desks and lots of whiteboards were common, and fresh fruit and/or baked goods were provided.

The striking thing was how much closer to real life the cartoon bad environments were. Most of the laughs came from recognition. The good environments on the other hand were largely wish fulfillment, and not just the ready availability of pastries. Floor space is expensive, particularly in London, and I doubt whether most companies would be prepared to devote so much square footage to pamper the developers. It is also unlikely that minions would be given so control over their own working environments. I was also amused to see that I had collaborated in designing an office which was basically open plan. I currently work in an open plan office (albeit cramped), and it can be very hard to concentrate. Sometimes a walled off cubicle seems a very attractive notion,

One interesting aspect of the process was how each team used the materials provided. In the first round we all tended to use the stuff closest to hand. The team with the Plasticine on its table had lots of blobs. Another team had been very creative with card. My team had the Lego so our office was largely built out of plastic bricks. However in the second round we had seen how the other teams had used different materials, so the good workspaces were a lot more heterogeneous in their construction. One team devoted lots of time to writing down the characteristics of their environments. Not surprisingly their models were the least-well realised. An object lesson in the perils of Big Design Up Front.

This session vindicated my decision to take a day's leave to attend the conference. "Logo, Plasticine and Playmobil? And you're trying to say you're working? Get outta here!"

Key lesson: developers want to be free range

Serious JavaScript

This tutorial was an attempt by David Harvey (Sibelius Software) and Peter Marks (indie) to persuade us that JavaScript is a proper richly-featured programming language, and not just a mechanism for undermining the robustness and security of web sites. I'm not sure they entirely succeeded. It didn't take long to discover some quirks in the language. For instance how JavaScript doesn't seem to be consistent in how it evaluates empty or undefined things.

JavaScript is an embedded language. It has no I/O routines of its own and a very small core library. It inherits most of its capabilities from the environment it runs in, which is part of the reason it has such a poor press. We normally come across it in browsers, which are Teh Suck as programming platforms.

JavaScript rarely raises exceptions. For instance strings are immutable, but we can assign to a string without an exception being raised (the assignment is just ignored). Another example: dividing 1 by zero returns infinity, a magic value like undefined or NaN. I suspect this tolerance of wrong code explains why so many JS enabled web-pages seem to hurl.

Key lesson: JavaScript - it's not just for irritating pop ups.

The Scoping Game

The last session I attended was a simulation run by Mark Delgarno (Acumen Software). Again we were in teams. The point of the game was to develop a range of mobile telephones. Marketing had provided us with a list of models, with mandatory and optional features and development costs. Each team started with the same pot of money. The challenge was to decide which features we would develop for a specific product, which we develop as reusable components and which we wouldn't bother with at all. The game was played over two rounds, with our revenue from the first round's models funding working on the second round's new models. Part of the fun was that we only knew the specs for the first three models. So we could hazard guesses about which features would be useful in the second round but we couldn't be sure.

Our team (Yodafone) spent a lot of time discussing the merits of developing Java as a reusable component in the first round, because the marketing brief hinted that it would be on increasing importance in the second round models. However, of the first round models, only one could use Java, which meant a return of a $2m on an outlay of $10m. So we decided instead to develop a reusable SMS component and a product-specific monochrome display for the starter model. We were the only team to bother with the entry-level model (I blame Idiot Toys). But our strategy paid off because Yodafone won the first round which meant we had more money than the others to spend in the second round.

When we got to see the next three models we had to develop a Java component, because it was mandatory for one of the models. However it was also a lucrative optional feature for the other two. So developing it as a reusable component in the second round still generated a profit. Building it earlier would have cost too much money without generating compensating revenue, whereas the reusable SMS component paid for itself in the first round and made lots of money in the second round too. The upshot was Yodafone actually increased its lead at the end of the game. Win or not win, there is no try.

Obviously this simulation is not very realistic. In real life it is often difficult to assign costs and predict returns in such a clear cut fashion. But it was a pointed lesson in making the best of constrained resources. I think something like this game would be helpful as a warming-up exercise to play with users at the start of a requirements workshop.

Key lesson: YAGNI rules in even the unlikeliest of places

Lessons for the UKOUG

Overall I found this to be a very invigorating day. I'll be honest and say that not much of it will be immediately relevant to me in my day job, but the MiniSPA experience gives me some lessons for me as chair of the UKOUG Dvelopment Engineering SIG.

With the UKOUG the rooms always have serried ranks of chairs facing a screen. By contrast the SPA rooms are setup on the presumption of interactivity, with six chairs arranged around smallish tables. In the UKOUG we ask every presenter for their PowerPoint before the day, so we can print them out and put them in the delegates' packs. The feedback form even includes a question about the quality of the presenter's slides. At the SPA only one of the three sessions I attended featured any PowerPoint at all, and that was just to set the scene. The session chairs often weren't presenting at all; rather they were acting as facilitators.

The other thing was that the sessions were about a variety of things. In the UKOUG we tend to have presentations about Oracle's product sets. So it's usually a cookbook format: how to tune a query, how to code a drop down list in JSF, how to call a web service. It's all good, useful stuff which people need to know but it does rather tend to induce a passive receptivity in the audience. By contrast, these SPA sessions tended to deal with practices, and in particular practice improvement. The games and exercises weren't a gimmick: active engagement with the topics stimulated creative thinking, which is the start of the improvement process.

So the challenge for me is to inject some of this excitement into the UKOUG or at least the DE SIG.

The Unanswered Question

In his introduction to the day, the SPA chair David Harvey said that developing software was the third most fun thing we could do with other people. I never did manage to ask him what the second thing was....

Programming: is it an art?

Ming Chow writes in his O'Reilly blog that a computer program is no different than a novel. Hmmm. Obviously both books and programs comprise words ¹ whose organisation is governed by syntax; both are written. But as activities writing a novel and writing a program are completely different.

For a start novelists are writing a story to please themselves. Programmers, on the other hand, are writing a set of instructions for a machine to meet their users' requirements. Novelists work on their own. Programmers usually work as part of a team. This means their work has to conform to common standards and have a consistent presentation. The only writers who have to work like that are a bunch of Parisian surrealist poets playing the Exquistite Corpse game.

I would particularly take issue with this statement:

Source code should be read like a novel, and great programs should be planned so like any great novel.

I don't think source code should read like a novel. Even back in the days when I was writing COBOL the code was modular. In the modern world of object-oriented programs, loose coupling, configuration files and code re-use any resemblence to linear narrative has gone right out the window.

Furthermore, few novelists do plan their novels in any great detail. Rather they start off with an initial idea, invent a character or two and see what happens next. It's not unusual to hear a novelist say in an interview that they were surprised by what one of their characters said or did. Most have only the vaguest idea of how the plot will resolve itself until they get to the end of the book. Which, on reflection, does sound a lot like eXtreme Programming. That doesn't do lots of planning up front either.

As someone who studied history at university rather than a scientific discipline I'm alert to the possibilities of regarding programming as an art. Although there are some similarities some similarities with novel writing I would regard film-making as a much more analogous activity. There's teamwork, the studio system, the need to meet a budget, open source as a Woody Allen/Russ Meyer independent movie maker, etc. Indeed, watching Lost In La Mancha, a documentary about Terry Gilliam's failed attempt to film Don Quixote was just like watching a film about a computer project crashing. But writing software is primarily an engineering activity. I find I get much more insight from pondering the metaphorical implications of structural engineering, classical architecture and town planning. These all feel like activities that have a greater bearing on programming than reading a biography of Charles Dickens.

---

^{1. Except for languages like BF of course. (back)}