Terrible, horrible, no good, very bad password policies

Image by Jason Dent

When I worked in the US Department of Defense, our computer systems had password requirements that were the stuff of legend. 3 lowercase letters, 3 uppercase letters, 3 numbers, 4 special characters, and they had to be at least 16 characters long. Plus they had to change every 30 days, and couldn’t be one of the last 25 passwords used. Because these were the requirements for our primary system logins, there was no chance of using a password manager.

So how did people handle this? Everyone diligently memorized the new password every thirty days, thankful that there were policies keeping everything secure, right?

Of course not!

Everybody kept their password on a sticky note stuck to their monitor where it could be viewed by anybody walking past. And the technical people who understood the risks of their password getting compromised? Well, they took a more sophisticated approach like tucking the sticky note in a desk drawer where it would take at least 30 seconds for someone else to find.

Continue reading “Terrible, horrible, no good, very bad password policies”

Lessons on resiliency from the James Webb Space Telescope

A rendering of the JWST, from NASA via Wikipedia

The James Webb Space Telescope (JWST) famously has 344 single points of failure – meaning that there are 344 individual things that could go wrong, any one of which would render the entire $9.7 billion space telescope a failure.

Building a piece of equipment like the JWST is pretty different from building businesses or software systems. Learning about how the space telescope was built and operated made me think a lot about resiliency though, and whether there is anything that a typical business can learn from NASA’s approach.

When you talk to business people or engineers about resiliency, they usually focus on achieving that resiliency through redundancy. If we can build this incredible space telescope without having each part be fully redundant, is there anything that can be applied in our approach to resiliency with the software and business systems we build and manage?

Continue reading “Lessons on resiliency from the James Webb Space Telescope”

Why I have joined Corso

I’m excited to announce that I’m part of Corso, a company dedicated to providing high-impact solutions to e-commerce merchants and their customers. Our immediate focus is to provide a service that solves problems with packages that become lost, stolen, or damaged during the shipping process, and to improve the environmental impact of orders being fulfilled into the hands of their customers.

My new adventure represents a big change for me since this is my first time working in the fast-paced world of e-commerce. I’ve enjoyed building and managing high-performance customer service teams in the past, and I’ve spent considerable time designing and implementing industry-leading technical solutions for those teams. Although e-commerce is new for me, the focus on providing an excellent customer experience through better technology solutions remains the same.

There are a lot of different reasons why I am excited about this opportunity. In no particular order, I wanted to share with you some of the things I look forward to doing:

Continue reading “Why I have joined Corso”

Doing root cause analysis the right way

Photo by Emily Mortimer

The concept of 5 whys is frequently trotted out as a formula for root cause analysis. Its proponents claim, “Just ask ‘why’ 5 times, and you will fully understand the root cause to a problem you are having!” The same concept is frequently applied to the process of researching and planning new solutions that your business can offer the market.

In case you aren’t familiar with the approach, the idea is to dig into surface-level problems to make sure actually understand the root causes. Asking “why?” 5 times as you dig deeper for each is the core of the method. Suppose our revenue is down 10% for the quarter:

  1. Why? -> Because we lost 10% of our customers
  2. Why? -> Because our customer service level suffered
  3. Why? -> Because we don’t have enough people to answer the phone quickly
  4. Why? -> Because our customer service agents are leaving for other opportunities
  5. Why? -> Because our pay and benefits aren’t attractive enough

While it is important to dig into root causes, anybody who has spent time with small children knows two things about asking questions like this: 1) there can be a lot more than 5 layers of “why?” underneath any given question, and 2) the answers sometimes stop being useful long before you run out of questions to ask.

Continue reading “Doing root cause analysis the right way”

Reviewing the Agile Manifesto

Photo by Kellen Riggin

I love the Agile Manifesto. Go ahead and visit agilemanifesto.org, bask in its turn-of-the-millenium aesthetic, and read it again. (If you are involved in software development, you have actually read it before since it only takes about 30 seconds, right?)

Back? Good. I like visiting it periodically just to be reminded of its principles.

Few things have resonated with me quite as strongly as the manifesto, and clearly it had a significant impact on the industry. The problem is, few companies actually prioritize the principles of the Agile Manifesto, despite claiming to be agile. In fact, a company claiming “We are agile!” can be a bit of a red flag at this point.

Continue reading “Reviewing the Agile Manifesto”

The process of mastery

Photo by Oleg Ivanov

During my childhood, I always wanted to play an instrument, but for a variety of reasons, it just wasn’t in the cards for me. As an adult, I still wanted to learn to play an instrument, just not badly enough to, well, actually put in the effort required. As we all must do, I made choices among competing priorities, and playing an instrument just never quite made the cut.

Learning an instrument is unlike learning most other things; compared to most other things we try to learn it has a big difference in the time required between “Hmm… I’d like to learn this” and “OK, I’m pretty good!”. Knowing from the onset what kind of commitment would be required was something of a hindrance, and I was never quite ready to make the leap.

With that preamble, I am happy to report that I am now 2 years into learning to play the guitar. While I am far from any sort of proficiency, I can truthfully say that I play the guitar even if I feel obligated to follow up with a quick “But I am still not very good yet”.

I’ve always thought that being able to acquire new skills itself is an important skill to have, and this has offered an opportunity to reflect on the learning and mastery process when it occurs over a longer timeframe.

Continue reading “The process of mastery”

Improving information technology efficiency with low-code

One of the most impactful shifts over the last decade in information technology has been the rise of low-code solutions. However, low-code and its potential impact often isn’t fully understood by everyone who could benefit from it.

One of the myths surrounding low-code is that these solutions will replace developers (wrong – but hopefully they help developers avoid lots of the tedious stuff). On the other side of that coin is the myth that these tools are pointless because you still end up needing to write code (yes, you still have to write code – but much less of it).

These myths both completely miss the power of these solutions. Low-code brings the responsibilities and influence of developers and non-developers closer together in the software development process. How?

Continue reading “Improving information technology efficiency with low-code”

Thoughts on The Wall Street Journal’s “It’s Time to Get Rid of the IT Department”

When the Wall Street Journal recently published this opinion piece, it caused quite a few ripples. I first saw the article mentioned in a sysadmin group where, unsurprisingly, it was immediately called a “hit piece” and derided. As the article spread it was clearly polarizing – there were some nuanced views, but especially for those who disagreed with the premise, there wasn’t much in the way of middle ground.

The more firmly a commentator disagreed with the article, the more their opinions seemed to reflect exactly the kind of thinking that the article suggests revisiting. With genuine consideration for the ideas presented though, I believe that many IT professionals and the companies they work for could significantly increase effectiveness throughout their organizations.

I’ve worked with many smart and talented IT department members who understand how to make technology work in the corporate world. The article isn’t calling out a lack of knowledge or capability on the part of the people inside our IT departments, instead, it talks about how increasingly critical IT is and how our expectations of technology in business should be elevated. It argues that having a dedicated and separate (and often isolated) department often misses the mark on aligning technology solutions with the needs of a company.

Continue reading “Thoughts on The Wall Street Journal’s “It’s Time to Get Rid of the IT Department””

Resolving the “Hasura Console is not able to reach your Hasura CLI instance” error

I recently ran into the error shown above (Hasura console is not able to reach your Hasura CLI instance. Please ensure that your instance is running and the endpoint is configured correctly.), where the Hasura browser console was reporting that it couldn’t reach the CLI instance. I had run ‘hasura console’ from a terminal, I was using the port that the CLI instance reported, and was able to navigate and see my data – so I was certainly confused.

The short answer to the problem: while the browser console needs access to a port for presenting the UI and interacting there (port 9695 by default), it also needs to have access to the migrate API port (9693 by default) for some functionality. If you see this error, check to see that the port in question is fully exposed and available to your browser.

For some reason, Google doesn’t seem to have indexed a single instance of the exact error message given above, and I hope this can help somebody who comes across the same problem.

Continue reading “Resolving the “Hasura Console is not able to reach your Hasura CLI instance” error”

Book notes: The Halo Effect

Illustration from the book cover, Simon & Schuster

If you have spent any time at all in the world of business, you will have come across different books that claim to have insight into how you can run your business better, be a better manager, and be more successful.

We’ve all read a lot of these books, and many of them suffer from different problems.  Often when I finish a book I can’t help but wonder things like:

  • “I just read that whole book, but it should have been a blog post… which could have been summarized in a paragraph” – sometimes a core idea gets expanded beyond its capacity, just to fill pages and justify the sale of a book.  Reading 250 pages for something that should have been 20 can be irritating.
  • “Did the authors run a study just to write a book? What were their motivations for their research?” – having quality data underpin any claim is a good thing, but the sources and motivations behind any studies and their accompanying data should be considered.
  • “Those conclusions sure felt forced… as if there was a point that the author wanted to make, and they were cherry-picking supporting information to get there” – sometimes it feels like the authors did a lot of jumping to conclusions, and you don’t come away with a lot of confidence that what you read is as applicable as the authors want you to think.

When I read The Halo Effect… and the Eight Other Delusions that Deceive Managers, it helped me put a finger on some of the uncertainty I felt when reading many popular business books and provided a framework to think more critically about the advice I hear or read.

Continue reading “Book notes: The Halo Effect”