Process of fixing a software bug

fixing-a-software-bug.md

Process of fixing a software bug:

A Guide for the Impatient Line Manager

(and how its interesting that only half of the time is estimatable

in a poorly run / bottom-dollar organization)

1. Reproduce; verify problem
   (not estimatable; can only set a maximum cut-off time based on pain/worth)

   in other words, if you could capture errors at the moment they happen (client-side error reporting),
   as well as the steps that led up to them (user behavior analytics, determinism, demo recording),
   this would represent significant savings on the time schedule and scalability of software operations

2. Automate reproduction; or find a way to quickly trigger the problem repeatedly for convenience throughout the subsequent steps
   (this one may not always be necessary, such as if the problem is easily reproduced by anyone,
   but when it is difficult to reproduce, or takes a long time,
   finding a way to automate it here will reduce time spent
   through the remaining steps.
   this one we can estimate the time to complete based on prior coding experience)

   in other words, as with number one above, if the error included a demo file which could be used to playback/replay or otherwise automatically reproduce the error, and step through like a debugger, this again would represent significant time savings.

3. Troubleshoot; identify cause
   (there is a chance the programmer will recall the code well enough to immediately recognize the problem,
   otherwise this one is not estimatable)

   as in number two, if we had the hypothetical capture and replay ability, this time would be nullified.
   There are systems that do this like Blizzard's StateScript (Google their GDC talks for Overwatch)
   Its a really smart move for large software houses.
   It requires the developers to have some understanding of deterministic computing though.

4. Think of solution
   (depends on problem complexity, can probably be estimated,
   depends on whether we will quickly band-aid,
   or think of best possible solution,
   which typically requires subconscious thinking for days or weeks)

   This is why humans still write software. The day AI takes this over, we're all out of jobs as a species.

5. Implement solution
   (the most obvious step, and the point of highest confidence in providing an estimate)

   The right investment in tooling can obviously help a lot here. A paid IDE can introduce tremendous efficiencies.
   But so can choosing the right language and technology stack.
   And, when building software for millions of users, partnering with other software vendors,
   and occasionally, when building a new category of software, permitting in-house innovation through research & development
   to try to cut down on waste and repetition, and to gain leverage over the software (ie. the fabled 10x programmer).

6. Test
   (can definitely guess how long it will take to run through a series of tests,
   and how thorough those tests should be)

   Test automation is clearly the biggest win here. If your CI/CD pipeline is mature,
   you will not have to do anything. You will commit and push your code to the version control repository,
   and it will trigger a set of tests, and alert you if any of them failed, once they finish running.
   Here you can go get coffee.

7. Repeat
   (the hardest thing to estimate, like predicting the future...
   will this problem rear its head again?
   will our fix cause other things to break?
   this depends on programmer experience,
   and familiarity with the system being worked on,
   and how clearly the business requirements were explained by the business owner)

   This is where philosophy and approach come into play. If you want to optimize this step,
   you have to have a deep understanding of the Zen of programming.
   You must take into consideration design patterns, standardization, and systems programming,
   and you must be willing to make bold steps in beating a path down the roads less traveled.
   Investing in experimental technologies... (e.g. analogous to how the SpaceX reusable rocket
   revolutionized the aerospace industry.)

   or the other side of the coin, which is building perfectly predictable software.
   software that has been built before, and will not lose value to be built again and again,
   such as business website templates, or shovelware game portals, etc.