Gather ’round kids. I’m going to tell a throwback story. It is the story of the “good ol’ days” of cowboy coding. It was a heady time. It was the early 2000’s when people like Mark Zuckerberg were building websites in their dorm rooms. When Zuckerberg launched “Thefacebook” on the Harvard servers (that ultimately took down those servers due to overwhelming load), I was developing an enterprise-wide content management system (CMS) for my university a few miles down the road. Alas, I had neither the forethought nor the wisdom to commercialize my product that I believe, to this day, was as useful and good as “Thefacebook.”
The History
When you work in higher education, you are used to having extremely limited resources that can barely meet demand. It makes for interesting work – you do what you can to meet need as best as you can with what you have. Sometimes, however, you meet an unmet need extremely well but still fail. That was sort of the case with my CMS.
By 2004 or so, demand for websites by units within a university rose significantly. The problem was, very few people had the skills to code HTML or use Dreamweaver which was typically what was available to administrators. There was always a gap (and, frankly, I think that gap still exists today) between the technology and services available and the skillsets of the people who will actually do the posting and updating of websites. I coined it the “web service gap” many years ago. Guess what? Nearly 15 years later, they are still talking about that gap and how to fill it. Anyway, I worked on the web services team. We were basically two developers charged with managing and maintaining the university’s website and a few high-level administrative sites and web applications. At the same time, we were charged with figuring out some way to meet the need of all these smaller units that needed a website.
The university decided to invest in an enterprise-level CMS. At the time, these CMSs were huge, complex and took forever to roll out. In my opinion, they were unnecessarily complex but I was a lowly programmer – what did I know? After the purchase of this CMS, work began to identify the first units who would go into it. Several months passed and no sites were launched. The pressure was on our team to deliver websites – whether in the expensive CMS or not. You see, our team wasn’t charged with developing in the new CMS. Instead consultants were brought in. One day, I had an idea to see if I could build a simple little CMS that might alleviate need until such time the big expensive CMS was ready for prime time.
In less than two weeks, I had a working prototype. In less than a month, we had more than half a dozen production websites in my CMS. Meanwhile, the big expensive CMS was still being configured. So we made the decision to put those in the queue for the big expensive CMS into my CMS until such time we could migrate them to the “better” one. That is how we positioned it – the big expensive CMS required more time and this little ol’ CMS would fill the gap until the big and “real” one was ready.
The Birth of Thinwire
As you might guess, my CMS was called Thinwire. And as you might also guess, it was a play on the big expensive CMS’s name. I won’t mention it here. Maybe you know. I think I still have some SWAG from them.
I wrote Thinwire in PHP with a MySQL database and hosted it on Apache servers. It was a basic system whereby configuration files were hosted outside the web root and the public, site content was hosted inside the web root. When I built it, I had the following in mind:
- First, and foremost, a department administrator should be able to intuitively manage the site content without extensive knowledge of HTML.
- It should be lightweight and easy to launch new sites.
- Training should take less than 2 hours.
We rolled it out with a few allies around the university. These allies would understand it was a work-in-progress and give us the feedback we needed to ensure it was easy to use and had the most desired features. The initial rollout was extremely successful. We then started lining up requests for sites in Thinwire. We were launching as many as 2-3 a week. The university was thrilled. It gave breathing room for the development of the “real” CMS and met an immediate need and did not “cost” anything. It was “free” because we developed it in-house (i.e., me) and departments and units nominated someone to be the “webmaster” who would go through our minimal training and write and post their content.
Too Successful?
At its highpoint, Thinwire had nearly 200 sites in it. The “real” CMS never had more than 5 sites in it and we even migrated some of those into Thinwire because it was so much easier to use and maintain. But the university was invested in the “real” CMS so resources were never truly allocated to Thinwire. Eventually, I burned out. All I did was support users and add a few features to Thinwire. It got tedious and, well, boring. These were the days when a developer could see a need, build a solution, launch it to amazing accolades then move on to the next problem. We were building and dropping applications left and right with no plan or process in place to maintain them. It took the “success” of Thinwire for me to see we could not continue to develop this way.
The first Thinwire site launched in 2004. I left that team in 2012. Since Thinwire was custom-built by me and I never had any time to document or train anyone on managing or maintaining the code base, I proposed to my department that perhaps I should migrate all of the remaining Thinwire sites to WordPress. The number of sites in Thinwire was down to about 80 then – because the “giddy” days of “I need a website!” were waning. I chose WordPress as the successor to Thinwire because I figured the university could more easily hire someone who knew WordPress than someone who could figure out my code.
[Sidenote: Not long after migrating to WordPress I learned of a fun thing that happens when you are in an open source app – as opposed to a custom-built app – hackers! Hackers love open source and will bombard you with attempts to hack the site thus sucking even more of your precious time when you are under-resourced. FYI, in the eight years Thinwire existed, there was never an attempt to hack any of the sites – mere days after migrating the sites to WordPress we started dealing with hacking attempts.]
Ultimately I left that team because of the “success” of Thinwire. It really did meet a desperate need but it was never supported and frankly I felt it was a waste of my skills. Thinwire needed support and training. It needed someone who could spend their time talking a user through how to bold and italicize content or to spend two hours talking about the need to use alt text and CSS in a training session. Ask a seasoned developer to do any of that and they will cringe. It is just not an efficient use of a developer’s skills. Believe it or not, but some element of Thinwire still exists today (rebranded – it is no longer called Thinwire and the “real” CMS it was named after is long gone — lasting less than five years). There have been two other people charged with maintaining these sites since I left. That second person recently left. I think they hire developers because they need them to maintain the backend, but they assume the developers will be fine with the support, training and project management of the users of the CMS. Clearly the need for a simple CMS is still there, now 15 years later, but it is still sorely under-resourced. That said, even if the “real” CMS were as good as promised, this support, training and project management piece would still exist and would still be under-resourced.
The Best Things About Thinwire
The best thing, in my mind, about Thinwire was how quickly we are able to meet an enormous pressure and need at the university. In a matter of months, dozens of new websites were launched for people who had been waiting over a year. While it was not perfect and certainly did not meet every need (find me a CMS that DOES do that!), it met the vast majority of need at the time. I loved being responsible for that.
Thinwire was also my baby. I birthed it. I wrote that CMS from scratch using countless sticky notes and whiteboard space to create the relational database I needed to most efficiently serve up the site’s content. I coded morning, noon and night because I could not shut off my brain and I absolutely loved every second of it. I have written other web applications since Thinwire, but only one is as nearly dear to my heart as Thinwire – a faculty profiles application I built six years ago when I started my current position. Funnily enough, I will be migrating that application to WordPress soon. Anyway, I was happiest when I was planning and coding web applications that met a real need.
Finally, I suffer a little from imposter syndrome. I am not a university-trained developer. I am, more or less, self-taught. When I proposed moving Thinwire to WordPress it was more so nobody could look under the hood at my code and point and laugh at it. However, once I started to plan the migration to WordPress I realized the backend I built for Thinwire was eerily similar to WordPress. No, I did not copy WordPress. I had not even installed WordPress anywhere prior to Thinwire launching. I chose it because it seemed to have the most user-friendly webmaster interface at the time. It turned out, migrations were a snap. I coded a little script that did some copying/pasting and rewriting but once I started the migrations, it took me less than an hour to migrate a site from Thinwire to WordPress. I was pretty chuffed about that.
Lessons Learned
As always there are lessons learned on any major project and Thinwire is no exception. While, overall, it was a success to the people who used it, it was not so well received after I left – the amount of time needed to maintain, support and train the users (who turnover just like any other job) was overwhelming and those who came after me were never really told this would be a big part of their job. I believe I set them up to fail because I did so much of the support and maintenance on my own time and never really documented the resources it really needed to be sustained.
Therefore, these are the major lessons I learned on Thinwire that I carry with me still today.
- Don’t build anything without understanding the maintenance, support and training implications over the lifecycle of the application.
- Advocate for resources to ensure the product can succeed longterm.
- Prepare for sunsetting the application when the time comes. Don’t let it just wither and die.
I do sometimes miss the early days of web development where we threw our hearts and souls into building something, basked in the glory after it launched then moved on to the next problem to be solved never really fully understanding what we were leaving in our wakes. I now think about the wake (and, more importantly, the total longterm cost) before I propose building or implementing a new technical solution for a perceived need. It’s not just about meeting the need – it’s about sustaining it over the longterm.
