Slack

This weekend I read the book Slack by Tom Demarco. What can I say? I enjoy reading 'old books'. I wasn't expecting to get much out of the book, since I learned most of what I would expect to learn about queues and slack time from the famous book, The Principles of Product Development Flow, but I learned quite a bit, and that's why I like to read old books.

If you haven't heard of the book or the term, the idea of "Slack" is that people who work mostly in the area of information need to work at less than 100% efficiency, perhaps even as low as 60% efficiency to be able to react quickly and be 'agile'. (I thought this was common knowledge by now, but I see on some of the recent Amazon reviews, that this idea still bothers people.) The book dives into how slack affects many parts of the business and helps make companies more flexible, reduce burnout, yada yada.

Things I learned from this book which surprised me:

• Companies go into litigation for reasons other than copywrite infringement, and often because of internal company politics.
• Google was not the first software group to learn that Psychological Safety was the most important quality of a team to get good outcomes. And now I really want to know why the Google research team didn't reference this book.
• This book is likely referenced more often than it is read (Shocker! 😲) The chapter on Quality is a must read. And it's this chapter that made me want to write about the book for Continuous Coding.
• This book also makes good arguments for "Servant leadership" and "Managing up" as being a by product of slack time, I had not made that connection before.

Continuous Coding, Quality, and Slack

In the book Slack, Tom DeMarco argues that Photoshop is the best software ever created (as of 2001) and he lists nine reasons why this is so. In order of importance:

1. It was unique
2. It redefined the photo industry
3. It redefined how people thought about images in general
4. It created new archetypes
5. It was well thought out.
6. It was fully implemented (no half baked features)
7. Amazing UI/UX
8. Great third party plugins
9. It rarely crashed or had bugs.

He then goes on to talk about how "Quality programs" or "Quality Assurance" is all about bugs and defects, which is only 1/9th of what makes something of good quality. Slack he argues, gives the organization the time to invest and think about the other 8 criteria.

In the book Accelerate , we learn that companies which use continuous deployment react to the market faster and gain a larger market share.

How do we make that possible? How do we use the feedback from our quick deployments to build a unique product, which redefines our industry or niche market? Well, it's not from automated tests, and it's not defensive feature flags, but it is from quality engineering. As software engineers we need to learn how to instrument our systems, not just to prevent network outages, but so that we can learn from how the software is used. We need good monitoring, and good telemetry, and most importantly, good conversations with our users. Through the iterative process of "build a little, ship a little", we must avoid the trap of "ship a little, and ignore the results". We have to demand some slack time to go out and talk to the customers, read the telemetry data, and gain insights which allow us to innovate.

Without Shabbat, I would not have so much time to think and improve, and a company without slack does cannot innovate. However, you might want to use discord instead... which is a horrible, terrible, no good, name for a tool which builds communities and helps people collaborate at the speed of verbalized thought.

Companies and products which are just single Dictionary words.

This week, Facebook renamed the parent company to "Meta". Along with Apple, Adobe, Slack, Discord, Razer, Alphabet, Amazon and too many other companies who were too lazy to create their own name. Allow me to briefly rant about how these companies and their products cheat people of good search results, and hijack words for marketing purposes. The least you can do is have a compound word, or make your official company name something larger, like "Unity Technologies" There is a movement that removes all labels and logos from items in their house so as to reduce the amount of advertising they are exposed to. Well, how do you do that when the very words we use in conversation not only get co-opted, but in the case of Discord, lose their connotations entirely!? Harumph I say... HARUMPH!

Innovation

They say that innovation comes from accidental discoveries, or insights. From Serendipity or our brains working on something subconsciously. We need creativity, and expertise in an area so that we can either increment or find a whole new paradigm. We can't force innovation. However, we can create an environment where we make innovation more or less likely to happen. This is true in the company and market scale, but also in our code bases.

What? Code bases? Innovation? Yes, we need to be able to innovate with our code.

• Firstly, we need time, and slack, to allow ideas to sit with us, to notice abstractions and to listen to the code.
• Secondly, we need to be able to talk to "the business", the customers, or domain experts, yes I'm talking about DDD here.
• Thirdly, we need to build our code incrementally and iteratively, so there is space for us to implement our innovations.
• Lastly, we need Courage. We need to be brave and believe that its possible to find something new, find some innovation, new abstraction, or new paradigm within our code that allows the business to solve a whole new class of problems. And we need courage to believe that we can do this in Many More Much Smaller Steps (h/t Geepaw Hill), without any major rewrites, no matter the quality of the code that we start with.