Literate Programmer

Recent tech reading

Recent notable reads in the tech space:

Content Strategy for the Web by Kristina Halvorson: makes a strong case for the prime importance of good web content and the discipline of managing content as related but distinct from user experience and information architecture.  A really interesting book—I’ve recommend this to colleagues in both web-focused and marketing/communication-focused jobs.  

The most important point, based on my experience in various projects, is that we commonly underestimate both the importance and the effort of crafting effective web content (there are some hilarious and cringe-inducing stories in the book about content tasks being left to the last minute on web projects).  

Why New Systems Fail by Phil Simon: I came across this one via Bruce F. Webster (who wrote the introduction), his “thermocline of truth” being one of my favourite pieces of writing on human factors in technology projects.  This is a high-level view from an experienced consultant of why IT projects fail to deliver on time, under budget or at all, with some stories from the trenches as well.

I really recommend anyone involved in IT projects within an organization read this one.  It’s focused on Peopleware-type systems implementations (HR/payroll/etc), but the issues discussed are universal ones.  Especially valuable for understanding how consultants view IT projects (if you haven’t worked as a consultant) and for thinking about the effective use of consultants.

Also fairly hilarious, for an IT project management book.

Public Libraries, Academic Libraries and Overlapping Concerns

I may write at more length about this later, but I wanted to get the main points down while my thoughts are fresh on this.  Myself and some other Toronto Public Library staff met yesterday with staff from the Ryerson University Library in what I’d call an exploratory session around library technology: “what are you doing?” and “how are things changing?” and “how are you using technology?”  Good stuff (and they gave us coffee and cookies, and the washrooms have sci-fi hand dryers)

This brought home to that while the library-specific service concerns between academic and public libraries don’t always have clear overlap, in the technology spaces we’ve got a lot in common.

Pain points:

• Legacy technologies at the core of what we do (MARC)
• Vendor solutions without APIs or separation of concerns that blackbox our data, identify us with problematic UX or otherwise have gaps (not just a knock on vendors—ultimately, we are the ones who decide what systems to buy)
• Difficulties in managing increasingly rapid technological change, leveraging emerging solutions, and keeping pace with changing expectations of users around technology

Trends / possible solutions:

• Building more of a library-specific development culture within our own organizations
• Involving users more in developing and refining technology solutions via user advisory groups, usability testing, diverse feedback mechanisms
• Shifting our criteria around systems purchasing to weigh things like APIs and data portability with more importance
• Uplifting the collective technical expertise of the organization, rethinking how staff training around technology is handled

I often think that libraries don’t spend enough time talking to people outside of the library world (specifically about technology, because it’s my area of particular concern, but maybe in general) but we probably don’t even spend enough time talking to each other about these things, especially across the academic/public library divide.

Non-homogeneous Web Content Management

• Data analysis and charting in a spreadsheet program like Excel
• Diagramming with something like Visio or maybe Balsamiq Mockups
• Prose bits in Word with the bits created in other programs incorporated into it (maybe just as static images)

Point being, the kind of content on an even moderately complicated website is often far more diverse than the kind of content that goes into a detailed report, and as a user you probably use a diversity of tools to create that report (then print it off, or convert it to a PDF for easy portability, or W/E).

Why do we so often persist in pretending that we can produce one-size-fits-all CMS solutions for web content when no one has been able to produce a satisfactory one-size-fits-all desktop software solution for far less complicated scenarios than managing modern websites?

Thinking about this seriously becomes increasingly relevant as it becomes more and more possible to move organizational production of content that previously required desktop software out into the cloud, and harvest it for website use via transformation patterns etc.  

(reflecting off of issues raised in Strategic Content Management and other thinking about what “content management system” actually means)

Using Google Docs as a CMS

In an attempt to prove (to myself, mostly) that some of my ideas are not totally ludicrous I have done some rigorous research around the concept of using Google Docs as a CMS, which consisted of typing “Google Docs CMS” into Google and looking at the first few pages of results.

It turns out many people have had the same thought.

Seriously—if the content you’re interested managing is simple enough to be captured in a spreadsheet, why not do something like this?  Make a Docs repository, give the right people access, and write a couple of pieces of glue code (since you can publish Google Docs spreadsheets to well-structured XML via RSS, you don’t even necessarily need to be using any “real” API calls—just scrape your spreadsheet feeds) to pull it into your website and format it nicely.

They said I was mad at the academy but I showed them all!

Thou Shalt Not Expose Back-End Data and Workflows to Users

I attended two presentations on Tuesday by the very interesting Rachel Van Riel of Opening the Book, a UK library consultancy.  She had a lot of good things to say about organizing and displaying library collections to improve services to readers of all sorts, but one that really stuck with me was her discussion of DDC and other methods of physical library collection organization, and whether or not they’re systems optimized for customer borrowing or for staff workflow (I’m paraphrasing a little here, so I apologize if I’m mischaracterizing anything she said!).  

Of course this struck me as very similar to principles of user-centred design for software application such as not needlessly exposing application flow and recognizing the difference between internal and external data models.  The similarity hadn’t really occurred to me before (perhaps an indication of how thoroughly librarians internalize established library systems of collection management as suitable for everyone).  So: a good question to ask about systems or processes that face users in the physical or technical space (or in the places where they mix)—who are they really optimized for?  Is there a way to redesign the user-facing aspects while retaining the necessary back-end complexity?

Recent Reading

I read a lot (librarian, duh)—mostly a mix of fiction and tech books.  A one-hour public transit commute is good for that.  Several of the recent tech books are highly recommendable (some good fiction, too, but this blog isn`t really about my fiction tastes):

Presentation Zen by Garr Reynolds.  Learn to do your presentations like Steve Jobs and all those cool TED presenters: slideware with lots of pictures, big charts and minimal text, and maybe a longer handout.  I’ve got a number of presentations coming up, so I’ve been reading a little about effective use of slideware (I hate all those bullet-point heavy PPT presentations when I’m subjected too them, but the rote is incredibly easy to fall into when designing my own presentations).  There’s a website as well.  A fast read, lots of good advice about how to use slideware effectively to accentuate a presentation.

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye.  Also available to read online.  Great book applying pattern language concepts to growing as a developer, within the software craftsmanship framework.  Possibly because my entry into real development was ad-hoc and apprenticeship-based rather than academic, I’m pretty sympathetic to alternate ways of thinking about building software to “software engineering” (anyway, Tom Demarco says software engineering as an idea has come and gone, and he should know, since he was pretty influential on the development of it—HA HA JUST KIDDING SOFTWARE ENGINEER BUDDIES! :D)

97 Things Every Software Architect Should Know, edited by Richard Monson-Haefel.  Speaking of apprenticeship, this book is a lot like getting to briefly meet a few dozen really smart and experienced people who think at a high level about building systems as their job.  They aren’t always in agreement with each other and they choose to emphasize different things, but a general picture emerges of how leading practitioners think about the task of building and architecting software.  A few of my favourite of the 97 things:

• Simpify Essential Complexity; Diminish Accidental Complexity (pg. 4)
• One Line of Working Code Is Worth 500 of Specification (pg. 22)
• Understand the Business Domain (pg. 60)
• Software Architecture Has Ethical Consequences (pg. 74—more on this one below)
• Heterogeneity Wins (pg. 78)
• Don’t Control, But Observe (pg. 96)
• If There Is Only One Solution, Get a Second Opinion (pg. 132)
• Choose Frameworks That Play Well With Others (pg. 168)
• Great Software Is Not Built, It Is Grown (p. 194)

My favourite is “Software Architecture Has Ethical Consequences”, which is from Michael Nygard.  I want to have a rubber stamp with that on it!  Here’s the whole thing (the entire book’s contents, minus some editing, are available via that wiki), but the choicest quotes for me are:

• “Every time I make a decision about how a program behaves, I am really deciding what my users can and cannot do, in ways more inflexible than law.  There is no appeals court for required fields or mandatory workflow.”
• “It’s not ethical to worsen the lives of others, even a small bit, just to make things easy for yourself.  Successful software affects millions of people.  Every decision you make imposes your will on your users.  Always be mindful of the impact your decisions have on those people.  You should be willing to bear large burdens to ease theirs.”

I don’t think I’ve seen the fact that design and architectural decisions in software have ethical implications stated so plainly or so well before.

EPISODE 1707: In Which I Follow Up On Something From Months Ago

This is a fast update, maybe with more to come later: after writing a note about it several months ago, I have finally installed the Google App Engine SDK and built enough of a basic application to feel confident in two statements:

The rise of robust and reliable Platform/Infrastructure as a Service providers add to the case for focusing internal library technical infrastructure on core and confidential services, and exploring third-party providers as the default for all other initiatives

(good definitions of Software/Platform/Infrastructure as a service in this Library Journal article from last year).

Libraries are already making ample use of Software as a Service providers such as Twitter, Flickr, Facebook, blog hosts like Typepad, etc.  Almost no one making decisions about library technology these days would seriously argue for duplicating a service like Flickr in-house.  Software as a Service solutions are typically cheaper on multiple orders of magnitude than an internally hosted platform with little or no loss of functionality.

The economies of scale offered by Platform/Infrastructure as a Service seem great enough that the decision sequence for library technology projects should be something like this:

1. Do we really need to do this project? (an important step not to skip)
2. Do we really need a custom solution?  Could we do this just as well or close to as well with a Software as a Service solution?
3. If we really do need a custom solution, can we build it using Platform as a Service/Infrastructure as a Service rather than on our own infrastructure?
4. If we think we have to add to our existing infrastructure (hardware, support, etc), why? (customer confidentiality/privacy concerns, critical infrastructure, regulations or legistlations, etc)

I should be clear that I don’t see “the cloud” as a strong argument for reducing technical staff in libraries, but for refocusing the nature of the work they do and the infrastructure they support: critical and core services, systems containing the confidential information of our customers, and systems we are obligated to maintain internally due to legislation or regulation.

The model for library technology has lot of potential to become like the model for library cataloguing

Your mileage on this statement may vary depending on how you feel about OCLC, but cataloguing is one of the areas where libraries (particularly smaller systems) really have managed to benefit enormously from economies of scale in their specific needs.  No surprise that OCLC has been exploring cloud services, with some attendant controversy.

Fundamentally, there is no good argument for reinventing the wheel over and over again for non-confidential public-facing library technology services.  Build it in the cloud (even better, build it in the cloud in collaboration with other libraries who have the same need, and open-source your code), and focus your internal infrastructure and supporting your genuinely unique needs.  This has been the model for library cataloguing for decades now.

In general these explorations have me more excited about “the cloud” than I have been previously.  Probably more to come in the future, (including maybe a link to what I’ve been building—IN THE CLOUD).

Tech Books That Have Influenced Me

I suspect most people who work in development have a list like this (I also suspect mine overlaps a lot with other people’s).  As I get older I find less and less justification for purchasing books on specific technologies or programming languages (partly because of the enormous amount of material online, partly because of services like Safari) but there are certain works dealing with more abstract / high-level topics that I keep coming back to regardless of their age (and a few about particular languages that deserve inclusion because of their influence on me).

Why do you care about my list?  You probably don’t!   This is first of all for me.  I’m dividing this into Formative (stuff from early in my career / even earlier than that) and Current (recent works that have influenced my thinking).

Formative

GWBASIC User’s Manual - on here because this was the first programming language I ever did anything with (at around age seven).  As I recall I spent most of my time writing “Choose Your Own Adventure”-style programs.  Good times!  And yeah, “GOTO statement considered harmful, but you have to respect your roots.  Back in 1987 we took what came with our install of MS-DOS and liked it!  As an aside, back when we did LOGO in Grade 4, I was mocked by other kids in my class for my endorsement of BASIC.  I consider it an early introduction to language wars.

Beginning Java Objects (Jacquie Barker) - this is the book I learned Java programming and basic object-oriented design principles with.  It might be dated for the Java language at this point, but it remains a great introduction to thinking in objects to solve programming problems.

Python for Software Design: How to Think Like a Computer Scientist (Allen B. Downey) - as someone who wasn’t academically a computer scientist, this book was a David Brin-esque uplift into thinking about programming.  I don’t have opportunities these days to use Python for work purposes, but it was a very formative language on my conception of “how” programming should be done.

Systemantics: The Underground Text of Systems Lore (John Gall) - not exactly a tech book, but influential on my thinking about the limits and pitfalls of systems for problem-solving.

AntiPatterns (Brown / Malveau / McCormick / Mowbray) - I have mentioned my love of this book before.  I think for anyone who’s ever worked on a software project or two before encountering this book, reading it is revelatory, and you begin to use it as a kind of field guide in identifying (and hopefully, correcting) issues in your personal approach to projects and within a larger project context.

Peopleware (DeMarco / Lister) and The Mythical Man-Month (Frederick P. Brooks) - both classics of the field to the extent that my commentary can hardly add more.  If you care about human factors in software projects, you need to read these.  Also both funny, quotable books in a field that doesn’t tend to have this as a characteristic of its bibliography.

Current

Designing the Obvious (Robert Hoekman) - recently finished this.  Don’t agree with everything, but some really interesting thoughts about applying the Pareto principle to web application design (build the 20% of the features that 80% of your users care about really well, ignore the rest, simplistically stated) and about iterative improvement.  Some of the best thinking I’ve read about the particular nature of web application design.

Applied Software Project Management (Stellman / Greene) - the best single-volume work I’ve read on everything you ever wanted to know about software project management.  Particular standouts: an explanation of the how & why of refactoring that almost anyone can understand, and a great chapter on human factors in change management.

Beginning Groovy and Grails (Judd / Nusairat / Shingler) - like a lot of web app people I’ve fooled around a little with Ruby on Rails, but this was the book that really turned me on to the possibilities of convention over configuration for web apps.

Side note: I got my first programming job about a year before I went to library school.  Programming / software design books were my “pleasure reading” for quite some time alongside the curriculum.  This is roughly how I ended up where I am today!

Design by Committee

clientsfromhell:

Client: “Sometimes the cursor on our site is the standard arrow, and sometimes it is a hand.”

Me: “Yes, the hand appears when you mouseover a link.”

Client: “Well, we’ve discussed it, and we’ve decided that we’d like it to always be the hand.”