What I did for the week ending 2018/06/02

I took advantage of the following learning opportunities:

• PowerShell Team: Using PowerShell From a Browser to Manage Cloud Resources by Danny Maertens on YouTube
• CSV, JSON and XML (Oh My!) by Jeff Hicks on YouTube
• WebJEA: PowerShell driven Web Forms for Secure Self-Service by Mark Domansky on YouTube

Perhaps more interestingly...

Last week, the library didn't have the books I was actually looking for, so I picked up The Phoenix Project by Kim, et al. I should have read this book a couple of years ago. I've seen this book recommended as required reading for greater DevOps understanding a few times.

I've been following the DevOps movement for a while, at a distance. I haven't paid much attention to DevOps's underpinnings or the scope of it's ideas. People don't hire me to re-engineer their business processes. As I did with TDD over ten years ago, I have adopted what I can of DevOps, according to my understanding of it.

"DevOps" is usually sold to technologists as tools (open-source, closed-source or roll-your-own), or perhaps some tactical approaches to things. Tools are easy to sell. (If we are talking about open source tools, "sell" is metaphorical but someone still needs to convince you that you need that tool.). You put up a Kan-ban board, you use git, you install a CI/CD system and you are done. Frankly, I've seen tools come and go (ah...Borland...) and I'm jaded. Most tools do not last more than a few years. I've seen waterfall projects outlast the tools they were based on. Many tools are just old wine in new bottles. (A new text editor? Sure, I'll give it a go. Is it better than the old one? Yes. Is it revolutionary? No.)

Concepts are not easy to sell. The book pushes the DevOps concept well beyond my previous understanding. I feel that my understanding of what the DevOps folks are trying to do has been radically upgraded. It encompasses tools, tactics and corporate strategy. IT isn't just something that "the IT department does". IT involves much of, if not all of, a company. whether the company understands it or not. IT should be seen as a competitive asset and data is as much the life blood of the company as cash flow is, or chargebacks between departments are. I've read that "going DevOps" requires a change in mindset, but I'd never understood the true breadth of what would be required, including from people who traditionally have as little as possible to do with IT.

All of the book's stories about WIP, queued work and rework all ring true. My first job out of school was in a factory. I worked on testing programs and hardware. I didn't really see the factory's products as my worry, but my boss did. He worried about WIP all of the time. I would see him out on the manufacturing floors, counting the pallets of unfinished goods that were stacked all over the building and frowning. Just figuring out how much product was in the pipeline was a problem, they would conduct "inventory counts" a few times a year, when nearly all other plant work was frozen for a day or more. I saw firsthand the chaos that happened when "finished" goods started failing tests and had to be reworked. Those tests were run by the programs that I wrote.

I've made note of many of the books mentioned after the end of the novel. I'll be following up on them at my local library.