I bought the book Dreaming in Code by Scott Rosenberg not long after it was published, and it's been sitting on my shelf, unread, ever since. I've read a lot of books on computer history - in fact, most all of them covering the period from the 1970s to the 1990s. After I arrived here in 1997 I've been close to many of the historic events that comprise a whole new series of books. This one, though, I should read for two reasons:
One, it's about the pitfalls and mistakes that can bring down a large software project. Some of the reviews said it can hit too close to home, but also make you feel better, as some of the top minds in the industry are not immune to the same mistakes.
Two, I have actually dreamed in code, which is the story I want to tell.
It was late in the early phase of a big project and I was responsible for building a multi-source enterprise data model for the entire hospital. The tools at my disposal were a SQL database, bulk data copies, stored procedures, and data transforms using a view/copy mechanism I developed for the physician directory years earlier - which was to be adapted one of three major portions of the enterprise architecture, the other two being physical locations and services provided.
The main problem was data flow.
I struggled for weeks with various data models, trying to fit them together, integrating the different source systems, keep the updates moving reliably from staging to production, catching errors before they do, and making the whole thing easy for one person to oversee.
Everything I tried either caused conflicting changes to overwrite each other, or entire data copies to fail. Each of the three main subsystems: physician, location, service, was an entire application data model in and of itself, and they were interlinked in increasingly complex ways. The end result, if it worked, would be amazing. Whether you're looking for a service, a doctor, or the nearest location for either, all the connections would be there.
If it worked.
(to be continued)