My DAM developer chronicles: 19 years at Digital Collections
To help me remember what I’ve been doing all these years at work, here’s some stories from my almost two decades of Digital Asset Management and Web development at vendor Digital Collections which are ending this month. Sorry for the lengthy post…
Before Digital Collections
As part of my Library and Information Sciences (LIS) education, I did a six-month internship at the text archives department of magazine publisher Gruner+Jahr. It was amazing to experience the librarian side of sophisticated, large-scale Digital Asset Management – see my blog post “Where have all the librarians gone?”.
I enjoyed our curriculum’s dBase and Turbo Pascal courses. But what I loved the most was the Microsoft Access 2.0 database programming we did for an architectural bureau – learning Access from scratch, over the course of several months, two fellow students and I wrote a real-world application for a real client and even got paid for it. During the following years, I kept doing MS Access work for that client.
Still a student (busy writing my diploma thesis [PDF]), I set up my first personal homepage on the Web (in handwritten HTML). Even though it consisted of nothing but a few links and some travel photos, it helped me land my first job the next year.
At Digital Collections
The people at Digital Collections (DC) hired me, happy to find a guy already familiar with some of their technology. They had recently switched from C and HTDL to PHP, which I had to learn on the job from scratch. Thies C. Arntzen, one of the company founders, was an amazing teacher and mentor – a PHP core developer, genius, and very fun to work with. With my lack of formal Computer Science education, he had to teach me not just PHP, but good programming in general: Coding style, DRY, clean object-oriented programming (yes, PHP 3 did OOP), separation of concerns, reproducible test cases.
Guided by my manager André Basse, I started adding features to DC’s “DC4” DAM system, a single-page Web application (lots of frames and document.write). DC4 was used by large publishing houses for newspaper/magazine archives, news wire feeds and image databases. It ran on the Oracle database, the Apache Web server and Unix (Solaris, HPUX, AIX, Irix, Linux) – all pretty new to me. The “vi” editor was especially scary…
The other genius at Digital Collections, co-founder Dennis Zierahn, taught me proper Unix-style programming: recursion, stacks, small, interoperable command line tools, inter-process communication. (DC4 ingestion and other backend processes were handled by command line PHP scripts running as daemons.) He handed his alternative DC4 Web UI over to me, which I ported from HTDL to PHP, wrote documentation for, and helped colleagues and partners get started with.
Ghostscript and Image Magick, IPTC IIM metadata and IPTC 7901 text were some of the things I had to learn about. But I totally fell in love with XML, using it in more places than I probably should have…
Aside from core product development, I helped out with a few customer installations. Editing PHP files on the live production server (remotely over an ISDN line) was a very special thrill.
During a long sick leave, my bosses surprised me with exceptional kindness and generosity. Together with Thies’ and Dennis’ uplifting and humorous personalities, the third co-founder (and CEO) Ole Olsen’s warmth, charms and fairness had shaped a remarkable company culture.
In the year 2000, the new DC4 UI was becoming a relatively stable product, so work shifted towards helping customers getting it installed and adapted to their needs. We travelled to Cincinnatti, USA to train our partner company GMTI, then to Barcelona for a requirements gathering workshop at a large Spanish newspaper. And I took over the customizations for a large German publisher of TV programming magazines, helping them search the DAM from within Quark XPress, and connecting it to their TV programme database. They taught me about ICC profiles and color spaces (RGB, CMYK).
We removed a few features from DC4 to create a “DC4 Lite” product. It didn’t sell well and got cancelled soon after. To simplify customization of forms and views, we created UI components that could be placed and configured from within Dreamweaver. While that seemed cool, it failed because our target users didn’t have a Dreamweaver license… We started the move from PHP 3 to PHP 4, and struggled with Internet Explorer 5 on Mac, the worst Web browser ever. A highlight was the whole development team’s visit to the German PHP conference PHP Kongress.
DC4 was rolled out to many more customers in 2001 – most of them overseas. Large newspaper publishers in Thailand and Malaysia started using it, and USA Today’s DC4 was put into production by GMTI whom we had visited the year before. I wrote custom code for these systems. For a Norwegian newspaper, I built an importer for archiving pages, articles and images from their CCI editorial system. And we optimized the product, learning about caching and Web application security for the first time.
I started a mailing list to keep our international distributors (in Scandinavia, Asia, Spain, Turkey) updated about new features. And we were all blown away by a new product called VMware which let us run a virtual Linux server on our Windows PCs.
Though we were sure that Web based DAM software was the way to go, photo editors frequently complained about a lack of speed and features compared to competitors’ native applications when handling lots of images. So we spent roughly two man-years in 2002 trying to develop a native Windows client for DC4 in Borland Delphi. It was a disaster (probably because all of us were new to Delphi); we moved way too slowly and finally cancelled the effort.
I became a bit bored with the old DC4 PHP code and started a few personal hobby projects to try out new PHP features, Smarty templates, and PostgreSQL.
In 2003 I worked on one of my favorite projects ever: Australian publisher Fairfax Media (Sydney Morning Herald, THE AGE) ordered a custom Web shop application to sell prints of their amazing photos to readers, and to license photos out to business customers. With the help of my manager and a designer, I built a completely new UI on top of our DC4 DAM backend – including e-commerce functionality and a custom admin UI for their staff. We flew over to Sydney for two weeks, and the Fairfax Photos site went live later that year. (Their current site is not powered by our software anymore.) This was my first encounter with SOAP, e-commerce, and a large public Web site.
But our DC4 product was growing old, so we started to develop its successor, the DC5 DAM system, as a full rewrite. Sadly, the geniuses had left the company. But it was amazing to start a new product from scratch for the first time, together with my passionate and inspiring manager and great colleagues: a cleaner software architecture, nicer OOP, the move from a single-page Web app to a simpler page-based UI. We learnt a lot of new stuff: XSLT (via Doug Tidwell’s book), LDAP, Unicode / UTF-8, and REST Web services.
My private work notes turned into this blog (I built my own blogging software, of course), and I published a tiny but well-received open source project, OracleEditor.php.
We spent most of 2004 building the first version of our new DC5 DAM product, learning a lot about internationalization (with the help of CLDR) and PostgreSQL along the way. We started using APD for profiling PHP performance. I discovered Nagios and introduced it to the company (but it took us a while to adopt). The pilot customer Fairfax Media in Australia went live with a pre-release version of DC5.
A large German magazine publisher became a DC5 customer, but needed a native application for viewing huge amounts of photos. Not wanting to repeat our failed 2002 experiment, we found a partner company to develop a Java application talking to our DC5 backend. I had read about RESTful Web services and created a more or less “RESTful” API for the communication with the Java client. For the same customer, I developed a two-way interface between our DAM and the Picturemaxx opengate (APIS) network for federated image search.
I started providing VMware machines with our DAM system pre-installed for colleagues, saving us time setting up demo servers. And we moved our development from PHP 4 to PHP 5.
At the end of the year, the company moved its Hamburg offices from Hammerbrookstr. into a former chocolate factory building in nearby Wendenstr.
2006 was a chaotic year: Several people left the company while we had to handle three large DC5 projects in parallel. We missed most deadlines that year. But we still built some nice things, like support for multilingual content for a Swiss publisher and the integration of a geographical thesaurus into search and edit forms.
We started to use the MantisBT bug tracking software. And because of performance problems with Oracle Text, we evaluated the FAST search engine (turned out it wasn’t the right tool for us).
Then my manager left, and I may have made a mistake: I declined the offer to co-lead the development team because I wanted to code, not manage.
Only four years after we had started to build DC5, we were already making plans to replace it with a new DAM system, in another full rewrite. Not only did the Oracle fulltext search performance problems force us to look for alternatives, but we also struggled with a design decision we had made in DC5: Our core development department had lacked the capacity to fulfill all customers’ feature requests. Most of our project managers were able to write PHP code. So we had split the application into a standardized backend and a sample frontend that was copied and customized by the project manager for each customer. Everyone was happy, until we figured out that bug fixes or new features in our sample frontend would have to be manually patched into every customer’s system, every time. This certainly didn’t scale.
So our new product DC-X (the obvious name “DC6” was rejected for some reason) would have a standard UI that we’d be able to update even after the project manager customized it. It would be a single page Web application with “Ajax” and drag and drop. Other good stuff that would appear in DC-X: Solr fulltext search, MySQL and Oracle support, Topic Maps, and a sophisticated workflow engine for scalable ingestion and export processes. Brainstorming and bootstrapping this new product in our team under our new manager Thorsten Mann was exciting.
In early 2007, I switched to the Mac. I started an internal blog on the company intranet (and learned that few people enjoy writing). The books I read that year, RESTful Web Services and The Pragmatic Programmer, influenced the design of DC-X.
I took over a half-finished, highly-customized DC5 project dealing with recipes and food photography. Something seemed wrong with the rights management code, but it was hard to pin down the problems since the rules were so complex. That was the first time I wrote unit tests – they helped me spot and fix several errors in our implementation.
After building and dismissing two prototypes for the DC-X UI, we ran out of time: The boss wanted to demo DC-X at the IFRA Expo. In just three weeks, the designer and I built a new DAM UI. This wasn’t fun; I almost burnt out from that pace and pressure. As a “thank you”, the company got me my first iPhone and flew me to the IFRA Expo in Amsterdam.
Ironically, that same year our team got a Scrum training to help us get started with agile development (which has a “sustainable pace” principle). I became the moderator of our “retrospective” meetings, and was invited to join the company’s management team “Jour Fixe” (this lasted for about two years, even though I wasn’t a manager) and went on a Denmark retreat with them.
I enjoyed reading the book Don’t make me think!.
Because some features were still missing, we decided to let developers (not project managers) run the first few DC-X projects. My job was to help the WESER-KURIER, the local newspaper in Bremen, migrate from DC4 to DC-X. We soon ran into trouble: The IBM GPFS file system we had recommended was great when it worked, but it blew up so many times that the project and our reputation took a serious hit. (It took IBM about a year to iron out all the bugs.)
I designed and implemented the DC-X rights management and asset usage metadata features. DC-X needed a Web service API, and aiming for “more RESTful” than DC5, I decided the Atom Publishing Protocol (AtomPub) was the way to go. (Not sure whether it’s the protocol’s fault or our implementation’s, but my enthusiasm for AtomPub didn’t last long.)
We considered creating a DAM UI with Adobe Flex. To gain some experience, we built the DC-X administration UI and a file uploader in Flex and learnt that we’d rather stick to HTML.
“My” DC-X project at the WESER-KURIER that had begun the previous year continued through 2010. It was a team effort, with me focusing on project management and integrations: The DAM had to interoperate with page planning software, the Atex Hermes editorial system, ePaper apps, SAP and more. For the first time, I took a front seat at a big go-live, which included training users and administrators, spending nights and weekends hotfixing bugs and adding features. Exciting and rewarding, and very exhausting.
This year, two of my favorite customers invited us out to celebrate successfully-implemented projects. Work is so much more fun when customers turn into real partners!
In my spare time, I prototyped an alternate, mobile-friendly user interface for DC-X. It would take a few more years for it to turn into an official product.
DC-X was being rolled out to more and more customers. We developers were in firefighting mode, adding features, customization hooks, working on scalability, usability, training admins and project managers, helping out during the go-live of each project. At the same time, we tried to do Scrum by the book, with well-planned, uninterrupted sprints…
I took part in the new product management meetings we established, and occasionally helped out as on-call engineer. The WESER-KURIER upgraded their editorial system, so I had to redo its DAM integration (and I had fun adding an SVG export to aid “visual debugging” of newspaper coordinates).
2012 initially seemed like “more of the same”: I kept doing a lot of work for the WESER-KURIER, including using DC-X as the backend for their public newspaper archive. My bosses complained that I spent too much time on that project (instead of improving the core product), but I enjoyed being so close to the customer. Together with our Scandinavian partner Teknograd, we reworked my mobile-friendly UI prototype. To further “eating our own dogfood”, I rebuilt the internal company blog to be powered by DC-X. (We later implemented our email archive in the DAM as well.)
But then my manager and a colleague left the company, and a few other people were let go because we had grown too fast. Restructuring and coping with the reduced headcount took a while, until my colleague Jörg Naß became my new manager.
There was even more WESER-KURIER work (Web CMS integration and more). We also built a nice custom Web site powered by DC-X: the public video archive for the German Federal Archives (Bundesarchiv), which went live in early 2014.
I was less involved with “my” customer WESER-KURIER; project management had already been taken over by colleagues anyway. This freed up time to finally turn that mobile UI prototype into a real product: I led the development of a tablet-friendly “Simple UI”, an alternative frontend for DC-X. This time, customers and partners participated right from the beginning, a stressful but important experience. We published a beta version, then paused the work.
For a Swiss customer, we integrated the DAM with the WoodWing editorial system.
We were invited to join the IPTC Machine Readable Rights Workshop as a guest, where I held a short presentation on rights management in DC-X. And with the help from Ralph Windsor (DAM News), I launched my hobby project Planet DAM.
We added sharing and upload features to the “Simple UI”, and used it as the basis for a public ePaper site (for browsing a Swiss company’s customer magazine). Work on the WoodWing editorial system integration continued, and I added support for AWS S3 storage to DC-X.
I had always been passionate about our product management meetings, so I was enthusiastic when my bosses asked me to run them as the product manager. (In that role, I never lived up to my own expectations, though.)
2016 started off with some turbulence; a bunch of large projects running in parallel required help from us developers, and more orders were on the horizon. Tons of work for everyone!
But we still felt that we had to invest in usability and fresh user interfaces, so a colleague and I were given time to think about a new UI in what we called the “DC Lab”. This time, we asked external usability experts, designers, and software development trainers to help us, and opened a Basecamp project site to discuss progress and questions with customers and partners. To me, that effort was the most exciting thing in a long time. We created a first prototype in time for the IFRA Expo, then began to slowly turn this into a real product, and learn new technology along the way (Git, PHP 7, Symfony, SASS…).
Unsurprisingly, implementing the new UI took longer than expected. We had to learn Symfony, and find the right frontend technology (Vue.js it is now). The first customer to use the new UI had other priorities than our “mobile first” approach, so we had to adapt our plans.
But the decision to build the new UI on top of our JSON API had been a good one; by now there was a lot of interest in using the JSON API from our customers, so everything we built for them helped our UI development (and vice versa). I even published a tiny JSON API client (in PHP) on Github.
I did a talk on DAM Trends in 2017 at the DC Customer Days.
At the end of July 2017, I left Digital Collections.