At OOPSLA, I'm planning to talk about NeoVictorian Computing. It's a big talk, with lots of side paths and a few surprises.

The slides are now available on my Lecture Notes page.

I'm going to talk about why we in computing seem unhappy, and how we might fix it.

Photos: Jake Hildebrandt, Lady Raven Eve

Why do I say we are unhappy?

• Everyone has pretty much the same computer. Your computer is my computer. Nobody is really very happy about their computer; the very best minds in the field walk around with old Dells or MacBooks, just like your grandmother. Almost everyone has pretty much the same software.
• Our tools and our rhetoric are often concerned with control of cheap, interchangeable labor: reuse, programming teams, patterns, workflow, specifications.
• Perhaps in consequence, people aren't eager to make software or to study computer science. Enrollments are down, even at the best schools.
• Our scientific conferences are filled with papers that focus on incremental improvements observed when asking unskilled laborers (whom we call "novices") to perform office chores. We call this "usability".
• Scholars interested in arts and humanities computing are strangely obsessed with box office and weirdly uninterested in making software, or making meaning.
• Our tone is often defensive. When we talk about the Web, about weblog journalism, about wikis, about computer games, we seems always to be apologizing or promising.
• We sound unhappy. Our best Web discourse (Tim Bray and John Gruber and Joel Spolsky and Scott Rosenberg, for example) focuses relentlessly on what a few vendors are doing, and often pleads with those vendors for small favors: new DRM policies for our iPods, or better perspective in the application dock. Our worst discourse (usenet, slashdot, valleywag, the comment section of any popular tech blog after comment #12) is consistently puerile; it's often hard to imagine that these are written by scholars, scientists and engineers, and not petulant children.

I think we all woke up one day to find ourselves living in the software factory. The floor is hard, from time to time it gets very cold at night, and they say the factory is going to close and move somewhere else.

Photo:Lewis Wickes Hines, NYPL 91PH056.029

What might cheer up the software world? The usual answer is: piles of money. Money is nice. You can exchange it for goods and services! But I think we want something else:

To follow knowledge like a sinking star,
Beyond the utmost bound of human thought.

That's what these machines are intended to do, and that's what we wanted to do. But this isn't a sentiment that fits well with Postmodern Programming. It's not really congruent with the early Modern purism of Dijkstra, or with the late modernist abstractions of UML. It speaks to the thought of an earlier age, refracted through the lens of our greater knowledge and our changed circumstances.

I see hints of similar yearnings all over the place, from steampunk to cosplay, from art to architecture to fiction. It's not just nostalgia or dressing up. It's not something we're borrowing from the arts. We are the arts.

I think we can learn a tremendous amount by pulling back from The Enterprise and putting our skills in the service of individual knowledge workers, real people doing important work.

Photo: Aldo Murillo

In this series of posts, I'm going to speculate on what's really wrong and suggest how we might begin to change things. The short version: The Arts & Crafts movement failed in consumer goods, but it could succeed in software.

I'm going to be using some slides from my upcoming talks on NeoVictorian Computing in this series, but my argument here will be quite different from the talks. Don't worry too much about spoilers.

We awoke one day to find ourselves sleeping on the floor of the software factory. Our software world is a world of alienation.

The laborer feels himself first to be other than his labor and his labor to be other than himself. He is at home when he is not laboring, and when he is laboring he is not at home.

Who would call a car company's payroll system, "home"? That was the task of the original Extreme Programming team. In software, much of our work and many of our dreams focus on Enterprise. Most of the rest concentrate on tiny tools that are expected to appeal to a mass audience, or grand tools — Office, open or otherwise — that can be imposed as standards on the world of work.

This isn't working. We've been stuck for years, the backlog never goes away, and we fight the same old fights with a new generation of management. The Enterprise is too complex, too turbulent, too confused, to be a fruitful place to study the craft of software. We don't know when it's right. Yes, we sometimes know when it's wrong, when we can't even deliver the software. But what is success? Praise from a self-interested manager? An incremental improvement in corporate throughput? A pile of surveys filled in by our students? A nice writeup in The Journal?

I propose that enterprise software is a hard problem that we can understand only after we solve an easier case, one that lies close to hand. Before we can tackle the enterprise, we need to write software for people. Not software for everyone, but software for you and for me.

Photo: Carter McKendry. Painting: Mark Bernstein, after a photograph by Lady Raven Eve, Singapore

By NeoVictorian Computing, I mean systems that are

• Built for people
• Built by people
• Crafted in workshops
• Irregular
• Inspired

When I say that software is "built for people", I don't mean some fuzzy notion that the software is intuitive or "friendly" or that it can be sold to millions of consumers. I mean, simply, that it offers some specific people three specific virtues: commodity, firmness, and delight.

It helps to get stuff done: not filling out forms or filing pictures or retrieving records, but the endlessly difficult, challenging, everyday stuff of understanding what is going on around us.

It doesn't break down in use. That doesn't mean it never fails: failure is part of software, just as brushstrokes are part of painting. Firmness means we can trust it, the way we trust the handle of a good hammer — including the knowledge that even good tools can crack.

And, sometimes, it makes us smile. Or it makes us think.

Photo: Natalie Tuke, Brooks Institute, Fiji

We can know when personal software is right, in exactly the same way we know when a theory is right, when a painting or a sentence is right. We don't need clinical studies or usability labs. We don't need box office numbers. We don't need to see the reviews from the newspapers or the VC's. We know.

And, yes, we might be mistaken. We sometimes deceive ourselves. It happens. At times, an audience helps us know that we're really right, and on occasion the approbation of our students or the cheering accumulation of sales might reassure us. But these are secondary; we have to start by knowing what is right and true, because we confront too many crucial choices to work from focus groups and popularity polls.

Wishard Health Services IT Manager Doug Miller begins a series on NeoVictorian IT.

Our shop is configured (admittedly somewhat unconsciously) around these principles. We aren’t a shop designed to build and maintain the sort of large enterprise software Mark discusses — we could never compete with the money and resources a McKesson or SAP or Oracle bring to the table, and aren’t particularly interested in doing so. Rather, our typical project is designed to meet the needs of one to maybe a dozen people. These are people who have a unique problem that no off-the-shelf software handles well.

The lore of software speaks of great minds and decisive moments.

In the beginning, so our myths and stories tell us, the programmer created the program from the eternal nothingness of the void. Whether it is Stallman typing teco macros and wearing out the shift keys; Chuck Moore typing backwards at Kitt Peak; Goldberg, Deutsch, Robson et. al. in the parclands of California; billg hunched over Allen’s Altair emulator; Bill Joy’s VAX crashing and deleting vi multibuffer support for the next ten years; Gabriel doing The Right Thing at Lucid; or Larry Wall doing whatever....

This is the language of romance and Romanticism, honoring the individual mind and body and its struggle against the elements and the Gods and the crashing VAX. This is the language in which we programmers secretly believe.

Photo of the photographer's wife writing in her diary in Kerala, India. By Erik Palkhiwala

We're told we ought not to believe it. We're told that programs come from teams, from corporate departments. Even those wild-eyed romantics, the agilists, imagine that the Customer is the ultimate arbiter.

Customers are as likely as anyone else to get things wrong. Yes, the customer may know their business, but customers are no less subject to self-deception than we. Businesses convince themselves all the time that they are making progress when they are not. Managers convince their bosses all the time that they are making profits when they are not.

Steampunk flat panel display by Jake von Slatt

Why do I call this NeoVictorian Computing? "NeoVictorian" is a handy and imprecise placeholder. I'm thinking of a very long 19th century that runs, roughly, from Sir Joseph Banks to Heisenberg, Pauli and Dirac. From Isembard Kingdom Brunel to Louis Sullivan. From Austen to Ibsen. From Realism and Romanticism through Impressionism. What connects all these threads?

In part, a belief in right answers, in the power of the artist or the designer to find true solutions to questions. Before this era, these questions were intractable. Later, it seemed there were no right answers at all. Now, chastened by our modern knowledge of the limitations of knowledge, of reason, of ourselves, we know that those bright certainties are not as certain or are real as we one thought. But we've spent our time mourning, in depression and cynicism and irony, and we've all been taught that, if truth is a slippery and uncertain thing, lies are very real.

We long for things that are ours, even if it's just our peculiar preference for a arcane latte at our favorite coffee house, the one where we have our own mug.

NeoVictorian Computing isn't about nostalgia for brass fittings and kid gloves, but rather about an underlying belief in true answers and true designs — even though we understand, now, that sometimes truth is situated, or contingent, or just a cigar.

Darby and Pritchard, iron bridge at Coalbrookdale. photo: Steve Geer

The NeoVictorian Computing impulse is Romantic, but it is also grounded in Realism. Not the realism of endlessly replicating variations on the same Human Interface Guidelines to keep Look and Feel from escaping from their cages, but the realism that asks us to look at things as they are and as they should be, and to do something about the difference.

Peter Turchi is also an invited speaker at this year's OOPSLA. In Maps of the Imagination: The Writer As Cartographer, he recalls that

One of the impulses behind 19th century realism was to tell the stories of people whose lives had not, previously, been deemed story-worthy. Another was to describe the world as it is.

Part of Realism is addressing the world as it is. Data are complicated; when we reduce everything to a hierarchy, we're distorting the world. Everything is intertwingled; when we pretend that clear signage will keep people from being lost or being confused, we're distorting the world. The audience is smarter than we are; when we pretend that real people can't understand inheritance, we're deceiving ourselves. Software that distorts the world can be a lie.

photo: Lady Raven Eve, Singapore

Honest materials are important to Realism; we show the painter in the studio because that's the painter's world, filled with clutter and turpentine. Realism prefers honest wood to cheap gilding. If something needs to be clay or plastic, let it be what it is: don't pretend it's sterling. Don't fold your napkin into a pheasant, and don't hide the structure behind layers of sham.

All the fuss about the icon dock's perspective and reflections, all the brushed metal windows and all the skinnable apps, they're all dross. It's simulated kitsch, so it does no particular harm, but it's a game Delicious Library has terrific wood shelves, but it's just a list of your stuff.

Limitations matter to Realism, too. We may struggle against them, creating paintings more real than photographs. We may accept them, knowing that brushstrokes and chisel marks are part of art. Either way, we are aware of them, and we want the viewer to know what's going on. Realism doesn't pretend to be a friendly paper clip: if you have got something to say, say it.

National Museum, Baghdad, 2003. photo: D. Miles Cullen, US Army

Finally, Realism accepts that real people have real work to do. It's not merely filling out forms or looking up facts: these are terrific things to study in the usability lab, but they're not what people need to do. People need to rebuild wrecked museums and wrecked families. They need to make sense of lymphoma, or partial differential equations, or RFC 822. People find themselves in astonishing, unexpected situations: one day you're a travel writer or an unemployed Republican protégé, and tomorrow you're going to be a minister in the Iraq reconstruction. How can you learn what you need to know, in time?

In 2003, most of those people failed. Their masters may have been scoundrels, but they were not. They had a job to do, and it appears to have been a job they could not have been expected to do. This a task for engineers: to build machines that let people do what they can't do with their bare hands.

Today, my computer is your computer. We all have, pretty much, the same computer. Yours might be a year or two newer. Mine might be green.

photo: Heidi Kristensen

Today, your software is my software. Some details might change: maybe you use Mellel and I use Word, or you use Excel and I use Numbers. Small differences matter. But it's all pretty much the same. People expect that they won't need to read a manual, that everything is just like it's always been and that nothing ever changes much.

Tinderbox screenshot. Pamela Taylor, Virginia Commonwealth University

I want this to change. I want a software world where we might again enjoy new software that does things we couldn't do before. I want software that fits specific needs. I'm a software professional; why should I be using the same tools as a sixth grader, or a professional photographer, or an interior decorator?

Why do we have so little variety in our software? One reason is that we ask it to do what it cannot, and we expect to do too little.

We should expect to learn. Sophisticated tools require study and effort, and they repay that effort by letting us do things we could not do otherwise. Calculus is a lot of work, but you can't understand physics or the stock market until you understand derivatives. Learning to draw the figure is a lot of work; once you do the work, you can draw.

Users and software designers should embrace personality and style. Software made by committee must adhere to the committee's standards, but software made by people and made for people may be infused with the creator's personal style just as it is adapted for the user's personal needs.

We should accept failure. Software fails in many ways. We have tried to change this, we have made great progress, but it is the nature of software to fail.

We once thought that there should be no errors, that errors were a sin. Errors are natural. I suspect we routinely spend $100 in development to catch errors that would cost our users $10. I know we routinely spend thousands of dollars to forestall cosmetic errors that will cost our users nothing save transient aesthetic annoyance. Operating systems are not the appropriate standard; since everyone uses the operating system all the time, and since operating system failure probably collapses the user's entire house of cards, it makes sense to over-engineer operating systems.

In the 19th century, British railroads went bankrupt building the rail system they wanted — with level grades and safe crossings and solid infrastructure. American railroads built cheap and fast, cutting corners with abandon. They accepted that they'd need to rebuild the worst parts in ten or twenty years, while the British rails would still be in fine condition a century later. The American answer was the right answer: yes, some American routes were built and rebuilt, and American rails suffered accidents and breakage, but some of those super-engineered routes are now little commuter spurs. Some are abandoned.

photo: Nathaniel Luckhurst

It's hard to know what is a defect, and what is merely a surprise. The cult of usability has enshrined the belief that anything a novice doesn't expect is a defect. If we're just interested in how many copies we can sell to novices, usability matters. If we're interested in utility

To follow knowledge like a sinking star,
Beyond the utmost bound of human thought.

then novice usability is a smaller component. I don't care whether the perspective of the application icons is consistent: I care whether they give me the information I need and offer the affordances to help me learn more and do more.

In the 19th century, Arts And Crafts sought an alternative to the seamless simulacra of mass production. Instead of using uniform dishes from The State Dish Factory, couldn't your dishes be made for you, and mine for me? There is no free lunch: if we want dishes made just for us, we accept that they'll cost more. And since the point is that the dishes are made for you by people, not by the State Dish Factory, we accept (and enjoy) things that come along with human involvement: they won't all be identical, we might sometimes see fingerprints, and sometimes we might detect the trace of the particular maker and their particular situation on a particular day.

It didn't quite work with Arts and Crafts, though plenty of artisan work continues today. The cost difference was too large. Worse, distribution was impossible with manual office procedures: it was barely possible to fill individual orders for identical commodities, and handling unique cases would have required armies of order clerks.

Filling our orders, B.W. Kilburn & Co's Stereoscopic View Factory. LC-USZ62-67035

But software is the stuff of thought. We customize it all the time, through preferences and scripts and macros and plug-ins. We can, and should, embrace the workshop, and learn to treat our software as an artifact and also as material we shape to fit our needs.

It's made by people; it will have brushstrokes and thumbprints. It is what it is: it expresses its nature instead of hiding behind brushed metal shams. It is made for us, and if the maker did not always anticipate everything, we respect the effort and the intention, and we take some responsibility for picking up the pieces.

Tim Bray likes the arts and crafts angle of my NeoVictorian series.

Mark Bernstein, the Tinderbox guy, is working on a series called NeoVictorian Computing which, while perhaps not quite as elegantly-turned-out as [Stephen] Fry’s œuvre, digs a little deeper. He is making a direct appeal for software to adopt the principles of the Arts and Crafts Movement. Since I am writing this sitting in a Stickley chair in a wooden house in the A&C style, I’m inclined to be sympathetic. Mark’s message resists summarization, so I won’t try.

My prose has been compared to Fry; life is good!

The NeoVictorian programmer works with myriad small pieces of code, connecting them in complex ways. She doesn't want or need to hide the segmentation or to cover up the joints.

Burnham and Root's Rookery Building, remodeled by Frank Lloyd Wright, photo by Willy Feng

The classical ideal was the unbroken column and the functional subroutine: call it once with the proper arguments and receive your answer. I remember programs that were vast stacks of cards, 3000 per box; I wrote a game that ran to fifteen boxes and had thousand-line modules.

Over the span of a generation, the size of our pieces has shrunk and the parts of proliferated. Modular programming suggested that subroutines fit on a page; in John Hsoi Daub's excellent PowerPlant framework (used in Tinderbox), it's quite common to find methods like LPOP3Connection::GetOneMessage that run to 60 or 80 lines of code. The smallest method body in LPOP3Connection is four lines, and that's unusual. All of our object code used to look like this: big objects with big methods.

We don't write this way very much nowadays. Agile Methods have something to do with it. So does refactoring.

A core cause, though, is a change in materials; just as the production of cheap cast iron transformed Victorian architecture, the discovery that method calls need not slow the program transformed the way we think about objects. And then there's test driven development: small objects and small methods are much easier to test, and the advantages of pervasive testing for avoiding reversion bugs are compelling. (I've never been a fan of methodologies and I hate anything that slows down coding, even type declarations. But Test Driven Development really has transformed my code work.)

If you're going to have lots of small parts and lots of small methods, closeup views are going to seem complicated. If you're going to build an office building or a railroad station out of small pieces of iron and steel, you're going to have lots of members and lots of rivets.

You might try to hide the complexity. But NeoVictorians ask, "why?" The parts are there. The rivets are there. Covering them with a facade makes them seem simpler, but if you need to poke holes in the facade for testing and to get the objects to do what you want, the facade becomes a sham -- a frilly cover that's supposed to hide the legs but just attracts dust.

The visuals from my OOPSLA talk on NeoVictorian Computing are now available from my Lecture Notes page. (I may try to provide audio as well in the future; because this talk includes extended sections in which the visuals act in counterpoint to the lecture, it might be hard to follow from visuals alone.)

We fly across continents to vast technical conferences. We meet in glittering ballrooms, filled with our colleagues. We are, it seems, miserably unhappy.

Peter Merholz is president of Adaptive Path. He does User Experience. He went to DUX last week. It's a user experience conference. He should be happy as a clam. Instead, he's twittering in the middle of the second session:

The moment an academic takes the stage, the conference screeches to a halt.

Dave Winer has written a lot about the failures of conferences over the years. He just wrote about why most conferences suck. Winer thinks it's because "we don't have enough to do." He once thought the answer was the audience-centered unconference, but is no longer so confident:

At first the joy of finding out that everyone has something to say is overwhelming, that was the first two BloggerCons for me. But after that, it wasn't that big a thrill, then it mattered more what they had to say.

What's the problem here? Part of it is inexperience; academics, especially, aren't trained in presenting. And where a corporate researcher might be on stage once or twice a year, academics meet an audience every day; it's nothing special, and the goal isn't to take risks and change minds. The goal is to get through the class.

Part of it is timid programming of safe, easy topics. At OOPSLA, when John McCarthy stopped to talk about the afternoon he wrote cons, nobody was reading their email.

There were a thousand elite software people in the room, and they all knew that McCarthy was talking about an afternoon in which he happened to invent garbage collection, dynamic languages, and pretty much all of modern programming. It was just an afternoon with nothing better to do.

But this only works because McCarthy (and OOPSLA) trusts us to know what cons is and why it matters so much. That trust is in short supply.

Still more fundamentally, the mass of guilt that weighs upon the field deadens our conferences. That guilt arises from the divergence of what we like from what we think we should like. We enjoy exciting new systems that do what nothing else could do; we think we should like systematic demonstrations that this widget lets students do a task 5% faster than that one. We enjoy daring prototypes and agile development; we think we should be planning our work and proving correctness. We enjoy astonishing code; we think we should write code so clear that our most mediocre students (and the management team) will grasp it without effort.

Guilt inhibits our joy in doing our work, and because we can't admit to that joy — we cannot be seen to exult in enjoying what we know to be wrong — we find our speakers addressing us in slow, measured tones about slow, measured studies.

We're setting the table for Tinderbox Weekend Boston this weekend. It's going to be great: everything from Tinderbox for plotting to using Tinderbox on location when the film you're shooting is not exactly what you had in mind.

We always make a few extra copies of the handouts as a Remote Membership package. It's not designed (unlike most everything else we do at Eastgate) to be a great deal. It's a way to support Tinderbox Weekend if you can't come. You get a copy of The Tinderbox Way, a CD filled with sample files and presentations, and your very own nametag lanyard.

For this batch, there's a little bonus: I spent an afternoon behind the microphone and worked up a screencast of the slides and audio from my recent OOPSLA Lecture on NeoVictorian Computing. So, if you'd much rather watch and listen to the talk on your iPod than read about NeoVictorian Computing here, now you can.

We've only got a few extras; get 'em while they're hot. All gone! But we'll have some extras for Tinderbox Weekend San Francisco, December 1-2.

Gavin McGovern thinks that some of our conference guilt comes from not being in the moment.

So to that guy that was sitting next to me, typing madly and muttering to himself, during a really interesting session, I wished your batteries died and you lost all network connections and your pen ran out of ink.

I suspect, though, that sitting around the conference table on the beach at Troy, the wily Odysseus spent a fare amount of time composing witty dactyls. I bet that plenty of salesmen at the proverbial annual shindig spend the sessions planning just how they're going to close the deal, make the quota, or spend the night on the town.

There's a reason we aren't in the moment; we aren't paying attention, because we can't admit to enjoying the parts of our work that delight us, and we don't want to admit that the rest is slave's work, unredeem'd.

At OOPSLA, Fred Brooks, Jr. (The Mythical Man Month and a legendary software manager) showed a slide that compared two kinds of hardware and software designs: those with fan clubs (some of the examples are his, some mine):

• Seymour Cray's computers
• MacOS
• LISP
• EMACS (or vi)
• ruby

and those without fan clubs

• IBM computers
• Windows
• COBOL
• Microsoft Word
• javascript

He observed that, pretty much without exception, the designs with fan clubs have conceptual integrity because they are chiefly the work of one or two people.

Now, it's also interesting to note that some of the unclubbable designs were profitable, and some of the clubbable designs were not. (Sometimes, you get intense fan clubs for products that are otherwise hapless and hopeless: the Amiga computer, say, or languages like APL or FORTH. I shared a cab after OOPSLA with a SNOBOL fan; that takes you back...)

What I want to point out is, whatever their success in the marketplace, the designs that inspire devotion are interesting and important because of the passion they create. We're much to quick to assume that the wisdom of markets is wise. It's not: bad timing or bad marketing or bad execution can matter, too.

One of the defining properties of NeoVictorian Computing is inspiration: the conviction that a design can be, and is, right. This need not mean the arrogant conviction that the design is perfect, nor does it expect or require a proof of optimality. And we don't require a supernatural insistence that some divine spirit instills the design into us. All we need is the sense that this is the best we can do; there might be other answers just as good, but this is your best.

You can't get that in a committee, by definition. And I think this property of conviction, integrity, and passion -- this quality without a name -- is of fundamental interest in a way that friendliness and usability and standards-compliance and fashion are not.

A maxim of Agile Programming is that You Aren't Gonna Need It, abbreviated YAGNI.

Conventional designs and specs tend to be too general and too elaborate. You start out with a data structure to hold a couple of People. Someone suggests that it would be better to have a vector, so you could have more than two if you need to. Then someone else wants to put it in a mySQL database. And then we're gonna run it on a remote system, on rails. It's easy to add generality to a spec. It makes you look really smart, especially when someone else is going to do the coding. But too much generality too soon makes the code age prematurely; you can get old, brittle, confusing code that looks like it's yellowed with age, even though it's not even finished yet.

Much of the time, this generality won't turn out to be needed. Even if it is needed, building it later means that you defer the development and testing cost, and that saves money. In the past decade, as we came to understand refactoring better, we have become much more comfortable with deffering these costs.

In the NeoVictorian workshop, YAGNI is balanced by the opposing sentiment: Go Ahead, You're Entitled.

Also known as 'Go ahead, live a little!' It's what your aunt might tell your mom when she can't decide if she should have some apple tarte with crême anglaise and a cute little glass of spätlese, when mom thinks she really should go fold the laundry.

Sometimes, it's worth building the good generality early, because it will open new vistas and new opportunities. You might, for example, see a place where you could get by with a pair of People but the code would be really elegant if you went right ahead and used a Composite. GAYE says, "if it's really cool, go ahead and invest now." It makes the code better, opens new vistas, new opportunities. It lets you try new things, because you've got a better, more general starting point for quick experiments.

If it doesn't work out, you can always refactor back to the simpler YAGNI plan.

What's the difference? The guy in the spec meeting is trying to look smart, or maybe just trying to look like he's paying attention and contributing to the team: the excess generality will be water for someone else to carry. The NeoVictorian is probably going to carry the water himself. It might be a little more work to carry that pail, but if it makes our part of the system better, that work is little to ask. Perhaps it will open new vistas, and perhaps it will let us build something else tomorrow, something that will matter.

Worst case, a little GAYEity might be an economic wash. On the one hand, if YAGNI applied then you've spent some development time building something you didn't need. But that time might have gone down the drain anyway, because the alienated coder with no opportunity to build a proud and soaring thing might take the afternoon browsing and brooding, or polishing her resume. Thou shalt not muzzle the ox when he treadeth out the corn, or fence the thoughts of your programmers when they're turning bits and rust to gold.

Though we have not found the silver bullet that would cure the software crisis by making programming teams vastly more productive, the last decade has seen a tremendous revolution in programming. The difference: while teams are only incrementally better, individual programmers can do vastly more. The largest programs that we can write have only grown modestly, but the largest programs that one or two people can write -- which is to say, the largest programs that an individual can understand -- have grown dramatically.

The kind of program that was a stunning achievement in 1967 -- a solid and efficient interpreter for an interesting new language, say -- was still a solid MA thesis in 1987. Today, we give that project to the summer intern.

The way this was expected to work was that programming languages would improve, gaining bigger and better abstractions so that programmers could avoid all that detail. The way this worked in practice, though, was not quite what we expected: languages did improve, to be sure, but the key change is that people mastered a new style of programming. It's not just object-oriented programming; it's small methods on small objects.

Kent Beck is one of the leading voices on the subject of small methods programming. Much of his work is situated in the context of methodologies for programming teams, Extreme Programming and Test Driven Development. This volume is all about coding: writing clear and sensible code to do what you want. It's the clearest explanation of small methods style I've seen.

Small methods programming is especially well suited to NeoVictorian Computing, because it assumes that the coder is free to design and refactor objects on the fly. Small methods, in the end, mean that you have to give developers a lot of design autonomy, so your design has to emerge from the hand of the artisan, rather than having it imposed by the grand architect or the design committee.

John Tolva picked NeoVictorian Computing for one of his top links of 2007.

Jason Kottke and Scott Rosenberg each mention NeoVictorian Computing.

Several people have emailed me to ask, "what programs do you mean, specifically?" This is a tricky question, of course, because software (like other works of art) carries with it a complex of circumstances and associations. Worse, there's no software canon, no body of work with which we can assume most people are familiar.

One hint, though: famous software that is intensely associated with its specific creator often (not always) has a strong NeoVictorian flavor. Reviewing the bidding, by "NeoVictorian" I mean systems that are:

• Built for people
• Built by people
• Crafted in workshops
• Irregular
• Inspired

If we ask, "what inspired systems were clearly built by individual people in small workshops”, some things that leap to mind are aspects of Stallman's EMACS, Iverson’s APL, Atkinson’s MacPaint, Marshall's VIKI, Engelbart's Augment, Berners-Lee's World Wide Web, Kapor's Agenda, Bricklin’s VisiCalc, Cunningham's Wiki, Herzfeld and Horn’s Finder, Crowther and Woods' Adventure. (I'm sticking to software that's ten or twenty years old, in part because I don't want to get into fights. The list is just a start. Your mileage may vary. Ideas matter: emacs vs. vi doesn't.)

I'm off to Cork for BlogTalk, where I'm planning to talk about NeoVictorian, Nobitic, and Narrative weblogs.

In my earlier Big Setpieces on weblogs, I looked at ways we could nurture the blogosphere and ensure the prosperity of the long tail. The way things played out, the blogosphere took decent care of itself, and the long tail was sold out, and then sold off as scrap to a couple of “social networking” sites.

This time, I'm sticking to description: what do weblogs want? In particular, what are the ideas that underpin blogging? Our era is understandably allergic to manifestoes, but weblogs do have Big Ideas, even while people pretend that they're silly little personal pages, generally incapable of serious thought and good, mostly, ads a parking space for millions of cheap ads.

A little bonus tension: I seem to have lost my voice, and my alarm clock. Stay tuned.

I taped a podcast of the first part of my NeoVictorian talk from Cork, Ireland. It's an interesting exercise on getting to know ScreenFlow.

I'd welcome comments on whether these are a worthwhile supplement to writing, or whether this is (as it seems to me) just a slower way to say what I'm writing on the blog.

Tim Bray observes that there's a lot of change going on right now in the software world right now, an unusual ferment in which established ideas about programming languages, databases, networks, processors, business models, and kitchen sinks are very much up for grabs.

Rob Rhyne has elegant slides (pdf) of a recent talk on “Breaking Consistency For Glory And Riches”, arguing for a more expansive and humanistic view of usability. It concludes with an interesting-looking spin on NeoVictorian Computing.