-
Notifications
You must be signed in to change notification settings - Fork 0
Articles
Here's the process laid out in sequence. After going through the steps, I'll provide more detail on each one.
- Figure out the symptoms.
- Reproduce the bug.
- Understand the system(s).
- Form a hypothesis about where the bug is.
- Test this hypothesis, and repeat if needed.
- Fix the bug! Check the fix, and repeat if needed.
We go through quite a bit of this process before even touching code. This can feel counter-intuitive and is difficult to get in the habit of, because the instinct is to dive right into the code (reading it and modifying it). Let's dive into each of these steps in more detail.
Why won’t people write specs? People claim that it’s because they’re saving time by skipping the spec-writing phase. They act as if spec-writing was a luxury reserved for NASA space shuttle engineers, or people who work for giant, established insurance companies. Balderdash. First of all, failing to write a spec is the single biggest unnecessary risk you take in a software project. It’s as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to “wing it.” Programmers and software engineers who dive into code without writing a spec tend to think they’re cool gunslingers, shooting from the hip. They’re not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for.
Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. ... We've seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we'll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.