I was reading Jerry Weinberg’s book, Quality Software Management: Vol. 2, First-Order Measurement, and came across the following:

Software’s nature is to be invisible, unless we work to make it visible…. During a construction project, we can see the building rising; but during a software project, all we may be able to see is a programmer staring at a screen.

This got me to thinking, as Jerry’s writing generally does. I recall reading sometime in the early 1980s, in some trade magazine, something to the effect that

You can see the progress of an electronic hardware project by the stack of revised schematics being generated. When you see a growing stack of program listings for the associated hardware, however, you can bet the project is stuck.

You cannot view the progress being made in a software development project by looking at the effort being expended. The progress can only be determined by the output achieved. And I can think of no better output to measure than Running Tested Features. That is, the software does what you, and the Customer, want–in increasing amounts–in a way that is measurable.

This is the purpose of “Acceptance Tests” in Agile Software Development. They don’t, as testing professionals often point out, prove that the software is completely correct. They don’t even force the Customer to accept the software and release it. But they do provide a measure of the progress in producing software behavior that is desired. They make the software visible.  Then you can see the progress.

Edit 3/29/2021: update link to Ron’s article