Category: Innovation

  • My Summer Reading List

    As many of us do, I have a much longer “To be Read” list than I have hours in the day to read. That said, I have a set of books I really plan to get through this summer, and I thought I would share (hey, it works for Bill Gates!). People who know me know I read, a lot. However I always fall into the trap of reading nothing but technology and business books. So in this list, I am trying force myself to include some broader material into my summer. The list is in no particular order, though.

    One Drum by Richard Wagamese

    This is one of those “not directly work related” books on my list (and really is first in my queue). Richard Wagamese (1955–2017) was an accomplished Canadian author and journalist of Ojibwe descent. He is best known for his works of fiction, non-fiction, and poetry that explore themes of indigenous identity, trauma, and healing. Wagamese’s writing was deeply influenced by his personal experiences, including his struggles with homelessness and addiction.

    In One Drum, Wagamese delves into a rich tapestry of Ojibway wisdom, known as the Grandfather Teachings. The book guides readers through essential life lessons—humility, respect, and courage. Beyond mere lessons, it also outlines accessible ceremonies, designed for anyone, in any location, solo or in a group setting. These ceremonies serve as practical tools to cultivate unity and interconnectedness.

    Stranger in a Strange Land by Robert Heinlein

    Purely a fun read. I have read Stranger in a Strange Land many times, but it has probably been 20 years. This has always been my favourite Heinlein novel, as it is full of provocative (especially for when it was written) ideas on religion, politics and sexuality.

    I recall the first time I read it, I was in grade 9 and had chosen it for a book report for school. When I showed it to my English teacher, he looked very concerned and asked, “Do you parents know you are readying this?” Of course they did – my mother recommended it!

    The CheckList Manifesto by Atul Gawande

    Ok, back to work! The CheckList Manifesto is an exploration of the role checklists can play in our professional and daily lives. The book asserts that checklists serve as a shield against failures, raising the bar for baseline performance. However, it also emphasizes that checklists are merely aids, and their efficacy is dependent on their utility; if a checklist does not help in accomplishing a task, it’s not fit for purpose​.

    I am looking at it from the perspective of “how can this help me tune processes in development and support?” Never know where you might find useful tools.

    Build by Tony Fadell

    Build by Tony Fadell is essentially about “how to build a transformative product-based business”. Fadell, known for his pivotal role in the creation of the iPhone and the founding of Nest, a smart home device company later sold to Google for billions, shares his unique journey and invaluable insights. The book charts Fadell’s career trajectory, including his early failures in smartphone development before the groundbreaking success of the iPhone, but it also promises advice for success at all career stages and tips for building successful product-based businesses and teams. The book provides a comparative analysis of Fadell’s guidance with the advice of other experts in the field, presenting a comprehensive resource for those aiming to create successful products, businesses, and teams.

    I am of two minds on this one, as I find these books are often way too anecdotal and seem to degenerate into “war stories” and “how cool were we” stories. Trying to keep an open mind though!

    The Language Instinct: How the Mind Creates Language by Steven Pinker

    The Language Instinct: How the Mind Creates Language by renowned Harvard psychologist and linguist Steven Pinker, argues that human beings acquire language primarily through an instinctual process. This instinct, which is guided by human instruction, naturally evolves as infants grow within their communities. Pinker’s work explores the fascinating intersection of linguistics, psychology, and child development, asserting that our capacity for language is not solely a learned skill but a fundamental human instinct​.

    This is another just-for-fun entry in the list. I have always been fascinated by language, how it developed, and specifically how it relates to our thought processes (is language necessary for cognitive thought? did intelligence come before language or did they co-evolve? Does the language we we think in constrain what/how we think?). This book is from 1994 but should still be interesting.

    The Order of Time by Carlo Rovelli

    More just-for-fun reading! The Order of Time by Carlo Rovelli is an exploration into the concept of time. In this work of philosophical science, Rovelli contends that time is not a constant or universally accepted entity as dictated by natural or scientific laws. Instead, he proposes that time is an illusion, sculpted by our individual realities and experiences. This innovative perspective invites readers to reconsider their understanding and perception of time​.

    Just something to keep my brain busy on a Saturday night!

    Clean Architecture: A Craftsman’s Guide to Software Structure and Design by Robert C. Martin

    Ok, pure work book here. I read a lot about “architecture” but tend towards discussions of specific architectures, practical considerations, pros and cons, etc. It has been a while since a I read about architecture in a broader, more general sense. I may actually have read all or part of this before, but anything by Robert C. Martin is typically worth revisiting.

    Clean Architecture: A Craftsman’s Guide to Software Structure and Design by Robert C. Martin, also known as Uncle Bob, presents a set of universal rules of software architecture aimed at improving developer productivity across the lifespan of a software system. The book builds on Martin’s previous works, offering not just options, but crucial choices for software success. It is filled with direct solutions to real challenges that could make or break projects. Readers learn what software architects need to achieve, essential software design principles for addressing function, component separation, and data management, and understand programming paradigms that impose discipline by restricting what developers can do. The book also provides guidance on the implementation of optimal, high-level structures for various applications and outlines how to define appropriate boundaries, layers, organize components and services. It discusses common pitfalls in designs and architectures and provides solutions to prevent or correct these failures. This book is considered a must-read for every current or aspiring software architect, systems analyst, system designer, software manager, and programmer.

    Staff Engineer: Leadership beyond the management track by Will Larson

    I came across this book last winter when I was thinking through a number of work-related challenges (replacing my Director of Development who had just moved on to a new opportunity, hiring/developing more senior resources for the dev team, and better defining what a career path in software/technology looks like especially for those not interested in management). I have read parts of this book already, but really want to read it cover-to-cover.

    Staff Engineer: Leadership beyond the management track by Will Larson is described as a valuable guide that elucidates the role of a Staff Engineer. Compiled from numerous interviews with established Staff+ engineers, the book offers diverse insights into the paths to becoming a Staff engineer and strategies to flourish at this level. Key ideas include self-scaling and growth, influencing others, and problem-solving. The book emphasizes the importance of writing for clarity and scaling oneself, investing time in high-value work, and balancing this with personal growth. It also underscores the necessity of being present in strategic meetings and taking the initiative to tackle and define problems.


    So there is my list for the summer (assuming I do not get distracted by something shiny!). So what’s on your list?

  • Introduction to Technical Debt: A CTO’s Perspective

    Introduction to Technical Debt: A CTO’s Perspective

    One of the most significant challenges faced by software companies (and as Watts S. Humphrey, the father of quality in software and CMMI, said two decades ago “Every business is a software business”) is managing technical debt. Adding to the complexity of the problem is the need to make the rest of the business understand what technical debt is, and how the business itself needs to own a significant role in its management..

    In this blog post, which is the first in a series, we’ll dive into the definition of technical debt, explore its types and sources, and discuss why it’s essential to manage technical debt effectively. 

    The goal here is not to explain Technical Debt to CTOs or other people in the technology group(s). I want to try to give you tools and language to help explain technical debt to the business, including the executive team, product management, etc.

    What is Technical Debt?

    Technical debt, a term first coined by Ward Cunningham in the early 1990s, is a metaphor that represents the additional work and costs incurred by opting for short-term solutions or compromises during software development. These decisions, while perhaps solving an immediate need or meeting a deadline, often lead to long-term inefficiencies and difficulties in maintaining or enhancing the software. Technical debt can be thought of as a metaphor for monetary debt, where borrowing money can help solve immediate financial problems but will incur interest and additional costs in the future

    Martin Fowler also has a great description of Technical Debt, or check out Wikipedia.

    Types of Technical Debt

    1. Code Debt: This type of debt arises from poor coding practices, such as lack of documentation, inconsistent naming conventions, and overly complex or redundant code.

    2. Design Debt: Design debt occurs when the software’s architecture and structure are not well thought out or implemented, leading to an inflexible or inefficient system. Note that Design Debt is not always due to badly executed or poorly selected design – often it can be traced to other problems like poorly defined requirements or time pressure. 

    3. Testing Debt: Insufficient or ineffective testing can result in undetected issues or vulnerabilities, which become more expensive and time-consuming to address as the software evolves.

    4. Documentation Debt: This form of debt is the result of inadequate or outdated documentation, making it difficult for developers to understand, maintain, or expand the system.

    Sources of Technical Debt

    There are several common sources of technical debt, including:

    1. Time Pressure: The need to meet tight deadlines often leads to compromises in code quality and design.

    2. Lack of Experience or Skill: Inexperienced or unskilled developers may introduce technical debt through poor coding practices or suboptimal design choices.

    3. Changing Requirements: As software requirements evolve, previously sound decisions may become outdated or no longer align with the project’s goals, creating technical debt. As well, efforts to make the system fulfill new and changing requirements can lead to Code and/or Design Debt

    4. Legacy Systems: Older systems often accumulate technical debt over time due to outdated technology, deprecated dependencies, or unsupported features. In addition, Legacy Systems can accrue technical debt merely by ignoring ongoing maintenance.  

    Why Technical Debt Needs to Be Managed

    Technical Debt needs to be managed, just as fiscal debt must be. Far too often I see Technical Debt treated as a purely technological problem which it is not. It is a problem which needs to be managed at an organizational level including all departments.

    There are valid reasons for taking on Technical Debt. Time to market is often one. Sometimes you have to “do what is necessary” and an 80% solution now is better than a 99% solution 6 months from now. This should be a conscious decision by the business however, not something that is hidden inside the Technology group and complained about by developers.

    Taking on Technical Debt without thought simply to achieve what are often arbitrarily defined timelines is not a good strategy. Doing so is like living your whole life on Credit Cards with no thought to how you are going to pay that debt off.

    I like to think of any Technical Debt decision in terms of risk and reward:

    • What are the business benefits or business value we are going to see from this choice (and over what timeline)?
    • What are the risks we are accepting by taking on this debt?

    In addition, no Technical Debt should be accepted without a plan for paying it off.

    Unmanaged Technical Debt has a number of impacts (and the longer it is left, the more it compounds, just like your credit cards):

    1. Maintainability: A codebase burdened with technical debt becomes increasingly challenging to maintain, leading to slower development cycles and higher costs.
    2. Scalability: Unmanaged technical debt can limit a software’s ability to scale or adapt to new requirements, stifling growth and innovation.
    3. Quality & Stability: High levels of technical debt increase the risk of defects and vulnerabilities, impacting the software’s overall stability and reliability.
    4. Team Morale: Continually working with a codebase riddled with technical debt can be frustrating and demotivating for developers, leading to reduced productivity and even attrition. Forcing developers to always do sub-par work just to make timelines is a sure way to break their spirits. 

    In the upcoming series of blog posts, we will delve deeper into the world of technical debt, covering how to identify, assess, and quantify it, as well as addressing it through development processes and cultivating a technical debt-aware culture. Additionally, we’ll discuss aligning technical debt management with business strategy and leveraging it for growth.

    Stay tuned for our next post on identifying, assessing, and quantifying technical debt, as we continue to explore this critical aspect of software development.

  • Welcome to The Monday Morning CTO

    Welcome to the Monday Morning CTO.

    Monday Morning CTO is a blog for small tech business CTOs (or those on the path, or anyone else who may be interested) who want to stay on top of the latest trends, challenges and opportunities in the world of technology. Whether you are looking for tips on how to manage your team, optimize your processes, leverage new tools or innovate your products, this blog will provide you with valuable insights and practical advice from experienced CTOs and industry experts. Monday Morning CTO aims to help you start your week with fresh ideas, inspiration and motivation to take your tech business to the next level.

    The name comes from the Monday Morning Quarterback idea – “experts” getting together on Monday to second guess what quarterbacks and teams did in the weekend games (apologies to those not familiar with North American football!). So here we will try to look back on things from the previous week including tech news or just challenges that have been front of mind and try to provide insights (hopefully without too much second-guessing!)

    PS – The irony in the fact that I am launching this on a Thursday is not lost on me! But then, the NFL often has the season opener on Thursday night.