About 3 years ago I received a phone call. I was working as a consultant, so I often got calls from people I didn’t know. It was someone I didn’t know, but he told me he worked for a company I used to work in. This was way back in 2006, and since then that company has been sold, acquired, management buy-outed, and integrated several times.
The person on the other end asked if I recalled visiting a local customer in Helsinki in early 2006. Remember, that this was around 2017, so I said I didn’t have a vivid mental image of such a visit or a project with the specified customer. He then said that I’d built a custom backup solution for their Windows Server 2003 that was running their Active Directory and other local services. And it had now broken and apparently did not do backups properly anymore.
I was slightly perplexed now. Something I’d built – perhaps over the course of a single consulting day – way back in 2006, had now broken. First, were they still using a Windows Server 2003? Second, hadn’t anyone replaced a system that was over a decade old? And third, well, let’s get to that in a bit.
The person speaking to me over the phone continued, “Jussi, as a true professional, surely you have a warranty for things you’ve built. So when can you swing by the customer and fix the solution?“. I wasn’t sure if I was on a TV show where they try to fool you into doing something foolish but funny, or if the person was for real. I asked, my voice perhaps cracking a bit – “Just to clarify, I worked at your current company over 10 years ago, and you are now asking me to go and fix something I did as an employee then?”. He confirmed and pushed forward – that he assumed people working in tech have a sense of pride for their work, and obviously this would be a gratis effort from me.
I politely declined and wished him the best of luck to find someone else to look after the issue. The solution I’d built, I later checked from my notes, was a relatively simple VBScript that packages Windows System State and crucial files in a .ZIP file and FTP’d that to a local service provider. It was an elegant approach in 2006 when the public cloud was still very nascent. Obviously I never heard back, so I’m confident the customer now has something more modern to ensure their business continuity.
I was busy at the time when I got this call, so I did not reflect on it any further. Something similar happened to a friend of mine recently, and this got me thinking.
Are we – as IT Pros, developers, and architects – building sustainable and long-lasting solutions? This is not to say that my VBScript-based backup solution was sustainable, but admittedly it had worked for a number of years, perhaps without any maintenance or care since I left the customer premises. It certainly worked better than my electric car has worked in the past few years.
It’s an interesting proposition – should we aim to build and code in the solutions that we can safely say will run nicely for a decade? What if something breaks after three, or five years? Is it for us to provide ad hoc troubleshooting or maintenance service personally?
I’m perhaps overly thinking about this, as I couldn’t say something like this occurred to me too many times in my professional career. Yet, it’s enticing to ponder just how well are we exercising our craft?
I also promise not to build any VBScript-based backup solutions for the rest of my career.