Accepting change is hard. Getting other people to change is even harder. The hardest thing of all is lasting change. Often, transformation efforts last only as long as the change agents are around; teams revert back to their old behaviors when they leave. This has a lot to do with confidence and buy-in. Change is usually rushed, and forced by “experts” who use phrases like “trust me” or “this is industry standard”. With a rushed process, it is easy for people to resist change, thinking that the change does not apply to their culture, problem or domain. But with some extra time, commitment, relationship building and empathy, lasting change is possible.
In the first episode of Devs Talking, get to know me, James and James as we talk a bit about what has impacted us the most in the last few years.
A big part of writing good automated tests is understanding why to write each test. While this seems obvious, people rarely think about it. When I write a test, I make sure that it achieves at least one of the following goals:
- Verify that the product meets the business requirements
- Give cover for future change
- Document intent
Around 11:45 PM night of April 7, 2017, the outdoor weather warning sirens began sounding around Dallas. It was a clear night, with no severe weather for hundreds of miles. Confused citizens called 911 to report or ask about the sirens, clogging lines and leading to
wait times exceeding six minutes. Others (like myself) called police dispatch lines and were told that nobody knew what was happening. Local news and the city were silent on all media channels – TV, web, Twitter, email, the Amber Alert system. The only sound we heard were the sirens, off and on for over an hour.
By the morning, it was reported that persons unknown had hacked into the warning system and activated the sirens. They had to be disabled manually by fire crews and would be unavailable for a few days while they investigated, updated and re-enabled the system. Thankfully, there was no severe weather predicted for this time.