[nonethewiser]

Here is an easy example.

You have a project that has both typescript and javascript. Someone makes a change in a JS file. They try to access a property of an object but there is a typo.

You could fix the typo and be done.

Or you could fix the typo, and convert the file to TS and make sure its typed.

[hbrn]

And then you get another typo in another JS file. So you convert it too. Rinse and repeat. In the end, all your application is now written in typescript, hooray.

Only the number of defects stays the same. Puzzled, you start investigating, and eventually you realize that all of those bugs were shipped by the same person. Turns out your whole TS crusade was a distraction. Even worse: you were optimizing for poor performers at the cost of your best performers.

But when all you have is a hammer, everything looks like a nail.

[mike_hock]

Yes.

It's the metaphor that doesn't make sense.

[canucker2016]

Here's a real world example.

On a product's multi-year death march, I look at the next bug assigned to me for the project-within-the-product I was on.

Over an hour of diligent debugging revealed the problem - the C++ code meant to do

    X = Y;

but someone had typed and committed:

    X == Y;

The destructive value assignment became an innocuous comparison, whose result is immediately ignored.

I decided to search the rest of the tens-of-KLOCs project for similar assignment-turned-comparison statements.

That's mindless and tedious work perfectly designed for a computer.

Several minutes later, after weeding through the false positives, I created bug entries for any offenders.

Did I stop there? No.

I connected to the source server for the entire product and kicked off the same search.

When the search finished, I separated the buggy wheat from the chaff and created bug entries accordingly.

This happened on the weekend.

When the product triage team met the following weekday morning, they saw all the bugs entered across the several projects in the product due to the same root cause - double equals instead of a single equals sign.

Management decided to take the next step. They bought a site license for a static source code analyzer. We integrated the analyzer into our project build process and ran the analyzer on each build and triaging accordingly.

Highest compliment I got for creating all this "extra work": "F*ck you!" said with a smile.

Did I stop there? No.

I kept my eyes and ears on the lookout for more possible typos. I would read commit emails and resolutions to bugs to see if the cause/fix would fit the model of "easily-found-via-grep".

I expanded my batch file to cover new cases and created new bugs when the batch file found them.

Did I stop there? No.

Eventually I hit the wall of diminishing returns for source code analysis via regular-expression searching.

I looked for a tool that could go to the next level.

At that time, the one scripting language available in our project's build tools was perl.

Off to the bookstore and I bought O'Reilly's Pink Camel Perl book.

A few hours later, I had a rudimentary source code analyzer that looked at lines of source code for typos.

I added more cases as appropriate.

But C/C++ source code isn't rigidly formatted and programmers wouldn't play nice and limit their code to one code statement per source code line. Preprocessor macros also confused the line-at-a-time script analysis.

So I bit the bullet and expanded the perl script to "parse" C/C++ code.

I added checks to make sure memory allocations were checked for failure (no exception-handling for memory failure in our codebase).

Did I stop there? No.

I publicized the script within the company, answered questions, listened to suggestions, and offered help to other product groups in the company.

A couple of other product groups integrated the script into their build process. Obviously it'd be better if each programmer would run the script before they committed modified code.

Did I stop there? No.

I had worked on the company's new signature product before the current project's death march had started. I still had access to that signature product's source code. So I would run my perl script against the product's source code. That product is huge. A source code scan over the network (my work machine didn't have enough disk space to enlist in every project in the product) would take all night. I had access to the bug database but I didn't know which source code directory mapped to which project in that product.

So I did the next, most annoying thing - I sent a cleansed list of defects to all the developers in the product.

Did I stop there? No.

The company had bought a static source code analyzer product and proceeded to integrate it into most of the company's products' development process. They created a stripped down version of the source code analyzer suitable for developer use before committing code. My perl script was obsolete now.

But that didn't mean others couldn't benefit from it even though the company didn't need it anymore.

I noticed a "call for papers" notice for an open source conference.

I emailed the company's legal department and requested to open source my perl script. Their reply: "Permission granted."

I wrote my proposal, sent it into the conference organizers, who accepted the proposal, wrote a talk, and presented at the open source conference.

Did I stop there? No.

Talk is nice. Code is better. I published/uploaded the script on CPAN (the Comprehensive Perl Archive Network - https://www.cpan.org ).

Did I stop there? No.

Around the time Coverity started scanning open source projects, I had downloaded the source code to several prominent open source projects and scanned their code and sent emails with possible bugs where appropriate.

[kazinator]

GCC has a warning for statements with no effect like x == foo();

  $ echo "void f(int x) { x == g(); }" | gcc -Wall -W -x c -
  <stdin>: In function ‘f’:
  <stdin>:1:22: warning: implicit declaration of function ‘g’ [-Wimplicit-function-declaration]
  <stdin>:1:19: warning: value computed is not used [-Wunused-value]