This post originated from an RSS feed registered with Python Buzz
by Ben Last.
Original Post: Something Wicked This Way Comes
Feed Title: The Law Of Unintended Consequences
Feed URL: http://benlast.livejournal.com/data/rss
Feed Description: The Law Of Unintended Consequences
Harry Potter And The Prisoner Of Azkaban drops the pseudo-Disney approach that Chris Columbus took (which at times made the hair on my head spontaneously curl up and burst into flame with annoyance with its over-literal interpretation) in favour of Alfonso Cuarón's much darker, more grown-up view of the parallel magical world that lies alongside our own. Lovecraft it isn't, but appropriately and disturbingly different to the everyday world, it is. I'm probably being too hard on Mr Columbus here. Doing the first two movies under that weight of expectation and in that time-scale can't have been easy, and inevitably he's going to fall short of somebody's yardstick somewhere, given that he can make but one movie per book and the number of different personal views of the non-Muggle world is pretty closely related to the numbers of readers. Which brings me, in a somewhat contrived manner, to a more software-related point.
Over the past few years, whilst working for the OddIdeasCompany that employs me, we've been bitten on our mutual and metaphorical arses several times by what I've pretentiously called the MarcusAureliusProblem[1]. That is; a set of people are assembled to discuss a project, but each has within their head a different conception of WhatItIs, just as a myriad Rowlingites fans conceived Diagon Alley in a myriad different ways. This is always true, no matter how good the communication between them; all one can do is seek to minimise those different views. However minor the mismatch, it has these inevitable consequences:
Discrepancies in terminology or visualization arise, that get in the way of communication. Ever had one of those meetings where half-an-hour is spent in arguing over a semantic issue that's pretty much irrelevant to the actual job at hand?
The differences multiply and grow if not caught early enough, leading to those awful moments when person A reveals what they've been working on, and person B realises that it's Different in a way that's going to screw something up.
One part of the solution to all this, of course, WritingDocuments that define what it is that's being done. This will, of course, reflect the opinions and viewpoints of the authors. Unfortunately, unless your environment is dramatically different to mine (perhaps some ideal software development planet, where specifications are transmitted directly from the mind of one EgolessProgrammer to another, directly rewriting the neural connections of the recipient), documents need time to be read and additional time to understand, and they don't get it. The Document becomes more of an exercise in ArseCovering: "it was in the Document, didn't you read it?". I've heard this referred to as ApparentMagic, implying a belief that "If it's written down, it becomes true".
Another parts is HoldingMeetings, wherein the project is discussed. Oddly enough, given my aversion to time-wasting meetings, I find this can be very effective as long as the focus is right. And the right focus, especially early on, is as far away from the code and the design as possible. Now, I could write "there are two sorts of meeting", but you and I both know that there are infinitely many ways to classify meetings, so let me try this: two sets into which we can usefully divide meetings are: InwardLooking and OutwardLooking.
The InwardLooking meeting focuses on how the problem is to be solved; on the representation of it, on the way in which it can be addressed by the technology at hand, or on the means by which that technology will handle the clearly stated technical requirements (probably in a Document). This sort of meeting tends to arise naturally whenever two or more engineers are gathered together. It's characterised by learned and erudite discussion of the relative merits of technical approaches. Depending on the nature of the several engineers there gathered, this can be fraught and difficult, but often it's extremely productive and generates great amounts of consensus in a short space of time.
The OutwardLooking meeting is more difficult to achieve, especially if it involves (as it must), the said engineers. This is because the focus must never be on the way in which the problem is to be solved, but on what the problem is. Okay, at this point you raise your amusingly-logoed coffee mug in scorn and say "Ben has discovered the need for requirements analysis, whoop-de-doo", or some local equivalent thereto. Allow me to attempt to manoeuvre my way out of that particular gravitational well.
Requirements, much as I value and appreciate them, are technical. They state in measurable and quantifiable ways, attributes of the system that can be measured to verify that the system is Right. An OutwardLooking meeting is not about requirements, it's about seeing the system as a Thing that lives in the real world, but from the point of view of the other people involved. Not in a use-case way, that captures the interactions of the system with human or other users, but in a conceptual manner.
This is all getting rather too abstract, so let me try and bring it back down to Earth, or at least the Earth-analogue that I'm currently inhabiting. It is remarkably difficult for an engineer to see a system from the point of view of a sales or marketing bod. Engineers (and note that I'm proud to call myself one) see systems rather like transparent clocks; the workings, or plans for them, are evident to us from the moment the idea of the system forms in our heads. Other people don't do that (I know this truth is self-evident, but it also need restating, often). Other people see the product as pink, or with shiny brass knobs on, or appealing to young teenagers, or mint-flavoured, or slightly rippled with a smooth underside. All these qualitative attributes matter, are not easily expressed in the language of engineers and are, to other mortals, as self-evident to them as the need for file-based storage or a mouse might be to us. Self-evident, and hence never spoken of. Unless one looks outward, sometimes.
[1] Not so much based on the old Roman himself, but on Hannibal Lecter's quotation of him, as the link reveals.
Previous Topic
