In 1946, computer scientist Grace Hopper recorded the first actual case of a bug being found. When her colleagues opened up the Mark II to see what was causing the computer’s errors, they found a moth trapped in a relay. To fix the problem, they had to “de-bug” the machine by carefully removing the moth. She taped the infamous moth into her logbook. Errors or glitches in programming have subsequently been called bugs.
Many things in life are features and not bugs.
Software “Bugs”
We have a standard format for reporting bugs. The reporter lists the steps to reproduce the bug. They say what they expected to happen and what actually happened (along with a screenshot and snapshot of the console).
This format allows the engineers to understand what is “not working” in the software. It seems tedious to list all the steps each time and to say what was expected vs actual. In a perfect world, software should work flawlessly. However, sometimes, what is perceived as a bug may result from not fully understanding how the software functions.
Let’s start with an example bug ticket–
Repro[duction steps]:
- Select Tasks & Services
- Select Services
- Create Service
Expected: The option to create a one-off service appears on the screen.
Actual: Only recurring services are available.
This ticket feels like a bug to the user until they understand that all tasks are one-off and all services are recurring. The purpose and use of “tasks” is different from “services.” A service has a recurring contract, e.g., for gardeners to come every week. A user wants to view all their services in one place. A task needs to get done once, which generally involves an action around a lease or a third-party vendor who invoices through Ender. One-off tasks go through a separate approval and classification process than a recurring service.
This purposeful delineation makes sense when you understand the product and end-user workflows. It’s not a bug, it’s a feature. The request, if any, should have been around UX improvements, e.g., creating tooltips explaining what services and tasks are or changing the workflow to be more intuitive.
People “Bugs”
This concept expands beyond running product at a company. It applies to people and institutions.
Real estate professionals often prioritize hands-on experience and direct client interactions over technical skills. This focus on the human element is critical in their line of work. A property manager may not be well-versed in the latest software technologies, but their expertise in tenant relations, maintenance coordination, and local real estate laws makes them effective in managing properties successfully.
The people doing the forward-looking work in real estate are the underwriters. Real estate is one of the few investments where you can accurately model returns. It becomes second nature to think this way in the real estate world. The downside is that groups often don’t consider how technology will impact them in the next five to ten years. The lack of tech-savvy people in real estate is a feature, not a bug.
At top startups, there are often “aberrant geniuses,” as Eric Schmidt describes them. They’re exceptionally talented individuals who may not fit into the traditional corporate structure but offer unique skills or insights that are invaluable to a company. Eric suggests that organizations can benefit from finding a way to accommodate these individuals rather than forcing them to conform to conventional norms.
To have creativity and excellence, you need aberrant geniuses; however, they’re aberrant. The company needs to be protected from them, and leadership needs to protect aberrant geniuses from the company. Their extreme disagreeability allows them to be great. It enables them to see the world differently and be creative in ways no one else can. It’s a feature, not a bug.
Understanding the incentives of how people and systems function leads to accurately predicting behavior. If you can predict behavior, you can plan for success.