This 47-Year-Old Classic Will Improve Your IT Skills

There are two kinds of people in the world: Those who know who Fred Brooks was and those who don’t. If you are an IT professional in the second group, you can step up your game dramatically by reading his seminal book “The Mythical Man-Month.”

Fred Brooks managed IBM System/360, the project that produced the first real general-purpose computer back in the 1960s. He distilled his experience from this 5,000-man-year project into the first edition of TMMM in 1975 and the expanded anniversary edition from 1995 stands on my bookshelf. When I meet other experienced IT architects, as at Software Architecture Open Space in Copenhagen this month, people will use phrases like “second-system effect” that originated with Brooks. He passed away yesterday after a long and productive life full of accolades.

To commemorate Fred Brooks, I’m inviting you to join a series of online discussions on IT best practices and what we can still learn from The Mythical Man-Month. We’ll meet on Zoom every Thursday at 5 pm CET = 11 am EST = 8 am PST. We’ll discuss one chapter from the book and how it applies to our work in IT today. I expect each meeting will be 30-60 minutes, and we’ll record it for those who can’t make it. We start next Thursday, November 24. Sign up here: https://vester.li/tmmm

Very Few Things are Impossible

You can get anything you want. But you have to ask for it. The U.S. had an election last Tuesday, and they still don’t know the result. We had an election in Denmark on Nov 1st. As usual, our result was ready before midnight on election day.

Now, we actually count paper ballots here in Denmark, and the U.S. uses computers. But that isn’t the whole explanation of why we are so much faster. The main reason is that we have decided that we want a quick result. Thus, we have a cut-off date for advance voting three days before election day, and all the advance votes are ready to count on election day. Vote counting is easily parallelized, and we have enough people counting. The U.S. could do the same, but they have prioritized other factors.

When IT says something can’t be done, it is rarely true. It might indeed be difficult, or expensive, or require you to give up functionality of higher value. If you work in IT, don’t say something is impossible. If you request work from IT, don’t accept the answer of “impossible.”

How to Avoid Techno-Blindness

Techno-blindness is a dangerous affliction. It is a disease of over-optimism mainly affecting people in the technology industry. The symptom is overconfidence that a system works as intended and a lack of awareness of what might go wrong.

Somebody in Moscow thought it was a cool idea to have a computer play chess with children, using a robotic arm to move the pieces. Until a child made an unexpected movement. The robot grabbed his hand and broke his finger. TuSimple is building autonomous trucks, and one of them accidentally executed an old instruction, causing it to turn left in the middle of the highway. Fortunately, nobody was injured as the truck veered across the I-10 and slammed into a barrier.

Important systems need independent safeguards. That means a completely separate piece of code that can intervene if the output of an algorithm lies outside some boundary. A truck shouldn’t be able to turn left at high speed. A robotic arm shouldn’t move on the chessboard until the player’s hands are off the pieces.

As a CTO, it is your job to ensure there are safeguards around important systems. You cannot depend on techno-blind developers to do this by themselves.