You have just read a blog post written by Jason McIntosh.
Thank you kindly for your time and attention today.
I quite enjoyed this New York Times feature by Jeremy Lechtzin that investigates the history of Brooklyn’s unusual street labels, filled with duplicate names and fractional numbers. Its current shape owes much to a ramshackle effort, all the way back in 1870, to repair a previous and also-bizarre number-and-naming scheme.
Perhaps the latter system ended up less chaotic than the former, but the project fell far short of its tidy ideal, and cost of huge sums of public money, time, and frustration. And as one with a history in both software development and project management in general, I found myself nodding along in sympathetic understanding to the well-meaning instigators of this 150-year-old disaster.
I also note that one of the main characters of the story, Brooklyn City Directory publisher George T. Lain, was only 24 when he began to agitate for a complete overhaul of the borough’s street numbers. He dreamed of the transformation it would bring to his business, while not caring much at all about how it might inconvenience literally everyone else. And I think: that sounds about right.
I too possessed a twenty-something’s unshakeable self-assurance when, in the middle-aughts, I committed a similar sin at my own workplace, too blinded by the utter brilliance of my own vision to seek input from anyone it would effect. You’ll never read it about it in any journal; unlike the fiasco Lain touched off, the scope reached only as far as a handful of science labs at Harvard. And, happily for those labs, mine was merely a software project, rather than a bureaucracy-laden civic overhaul: in the end, utterly forgettable, with no trace remaining of it today.
The scientists at these labs, you see, kept all their research data in Excel worksheets; innumerable separate documents bouncing around individual hard drives, with more generated by data-collecting robots every hour. The labs’ managers knew that this loose style left a lot of potential for digital publication and collaboration out of reach, and hired me to help invent design and implement improvements for collecting, storing, and sharing this data.
So, you know what I tried to do, of course: throw out those Excel sheets! Have the scientists instead use the glory of a full-stack bespoke web application! It would be glorious! There would be heat maps! I busied myself re-inventing everything that Excel could already do, except slower and harder to use, in the perhaps inevitable pattern of a young Perl hacker who dismissed Excel as software for normies. I may have conducted an interview or two about the researchers’ process, and let them tour me around the labs a bit, but I otherwise went it alone. I did not truly invite the researchers to work with me as co-designers, as I should have from the outset.
You can only imagine what a gut-punch I felt when I overheard a frustrated biologist dismiss my project as “this foolishness”, some time after it had started to roll out for use in the labs. The researchers could not help but see it as an obstacle, getting in the way of their work. Of course they did! I had doomed my effort through my complete failure to involve the project’s would-be users into its creation. They ended up with some weird thing made by an outsider, and everyone hated it. All that work ended up binned—and deservedly so—within a year or two of my departure from the job.
But I have, at least, a happy note to end on. When I read that story about the incompetent Brooklyn renumbering project, I did not think immediately of the quiet disaster at Harvard. I thought instead of my current job, where my hiring carries echoes of it: a technical writer invited to bring some order and focused attention to a heretofore freewheeling, developer-driven documentation process.
And I allowed the devils of Burn it all down! Rebuild in mine own image! to do their little dance, and then I dismissed them so I could turn my energy to asking those developers what’s worked for them so far, and research new ways to use the tools and techniques that the team already prefers.
I’ve learned a thing or two myself, since those days at Harvard, and I’ve built at least a couple of collaborative projects that didn’t collapse as soon as I took my hands off of them. I have a pretty good feeling that this project’s legacy will end up a little more orderly than the hubristic past misadventures of either Mr. Lain or myself.
Next post: I replaced my ancient iPhone’s battery
Previous post: How and why I deleted 40,000 tweets
To share a response that links to this page from somewhere else on the web, paste its URL here.