IT Lessons From My Son’s Homework

One night last week my son handed me a grammar assignment that he had done poorly on. He said he had the opportunity to redo it. And since I have a degree in English, I took a look at it. What I read shocked me.

I looked at the sections that were most heavily marked, and I noticed that almost all of the problems that were marked wrong were right. I started formulating a plan to drive my son into work the next day and confronting the teacher or the principal.

That’s when my son told me he had already redone the problems. Since he had made the changes on the same sheet with no indication that any updates had been made, I had no way of knowing. If he had noted each change on the paper, I could have followed along and not had such a near-miss embarrassing collision at his school.

When changes are not noted in what I will call the system or place of origin, the consequences can be catastrophic. If, instead of correcting homework, one of our engineers made a code change made to software without noting the change in the system of origin, our customers could suffer serious usability issues, and it might take us hours to uncover what happened.

Fortunately, that doesn’t happen here due to tight protocols and processes, but that is for another blog.

Anyway, in talking to our developers and operations managers, it’s clear that they have some pretty stringent processes in place to both limit “rogue” development and deployment while simultaneously encouraging experimentation.

It’s a DevOps thing, and you’ll be reading more about it in future blog posts, so stay tuned. Consider it your homework.

Request a demo