This month the topic for T-SQL Tuesday comes from Andy Leonard, whom I reached out to be a host. I was running low on hosts last year, and Andy agreed to help me out. I had expected something on ETL, but I was surprised with this one.
Andy asks us about managing technology change. He does mention how SSIS changed as he was writing a book, meaning that things he’d learned while a project was underway no longer applied. That’s a scary place to be, and it’s one I’ve rarely experienced.
Avoiding Shifts
One reason I don’t like to test beta software, especially from Microsoft, is that the APIs, the functionality, the effects can change. I prefer to have something fairly well settled before I spend time on it.
I took a chance early on with Windows 7, when they had the “skydrive”, which become OneDrive. I could sync files from my desktop to laptop, and for someone that travels a lot, this was fantastic. It worked through the beta and until a few years later. At some point it stopped and I moved to Dropbox. I still use DropBox, even though this was reborn as OneDrive and enhanced to allow me to have personal and business “OneDrive” running at the same time.
Moving on from Immature Software
I don’t like to abandon software, and sometimes I can’t. For me, I’ve been involved with some of the products that Redgate Software has built. I often see things early and test them to give feedback to developers. This means I sometimes see things before they work well, or even before the development teams might know what they want to build.
This has happened a few times, but a couple years ago we were evolving one of our products to expand capabilities for customers. I thought we were moving in a good direction and spend quite a bit of time evaluating how the software worked. I was even starting to incorporate this into some automation pipelines and build demos, when the product direction shifted.
A fair amount of code I’d written had to be abandoned. I felt as though I’d wasted some time, but as I stopped to think, I realized that I’d been learning and growing in this area. I’d understood how things worked, and while I had to write new code, I was able to write it quicker because I understand the general problem space already. Even though I had to expend other effort, I’m not sure my early work was wasted.
Fortunately, I didn’t have deadlines for a deliverable. If I did, I might have been more upset. If it happened in the future, while needing to work more to get things done might annoy me, I’d likely understand that the growth and knowledge mean I don’t have to double my investment, and likely I’d be better positioned to write better code the second time around.