Our host for this month’s TSQL Tuesday is Andy Leonard (blog|twitter). He’d like us to discuss how we handle changes in technology. Particularly unexpected changes.
For me this was kind of hard. I can’t think of a time when technology has changed on me without ample warning. The vast majority of the time if technology is changing it’s changing because a new version of the technology is coming out. Changes like this are easy to see coming and general happen after a long, carefully thought out, migration. Usually with lots of testing (yea, ok, maybe not, but at least the plan is for testing). I could see this happening under a number of circumstances though.
- I’m writing a book.
- I’m in the middle of writing a piece of software and a new version of the software has just come out and it has features that I need or are just too good to pass up.
- The cloud. I mean the cloud just changes all the time.
- A patch/cumulative upgrade
Those last two are the biggest risks to me. I have to say though it isn’t something that worries me much. I’ve had jobs where the company motto was almost Change for the sake of change. I’ve learned that it’s going to happen and it’s not really worth sweating it too much. In the case of software I’m kind of of the mind that you should always be refactoring/updating your software anyway so there should be time built in to deal with this type of thing. Technical debt is a thing and unless you keep it in mind and in your planning at all times it can become a real problem. Basically I guess I’m saying, pad for unexpected issues such as technology changes. I mean I can’t tell you how often I was told stories by speakers about the laptop going out, the laptop getting stuck in a multi hour update, any number of hardware and software changes and problems. The common themes were planning ahead and coping gracefully. Because really what else can you do?