What are we doing?

This should be self-evident: any endorsement of a process or tool, whether in life or in software, should have the burden of explaining its ground purpose.

This purpose could be anything but without making it explicit we cannot say we are behaving rationally. We have no basis for our hopeful outcomes. Without explicit purpose, we're just talking air.

Eat cheese.

Here is a recommendation with no purpose.

Eat cheese because it tastes good.

Now we have a reason, now we can have confidence in our behavior.

When it comes to software construction, the only worthy purpose is throughput. Throughput now and tomorrow.

Another word for this is productivity.

I code too much. I love to code. In my off hours, I play with logic systems and UI frameworks and data platforms. I cut my fingers. I get my hands dirty. This play is fun and edifying.

Fun is a good purpose. Learning is a worthy purpose.

But we're talking about software construction. And this is not that.

That is play. Software construction is work.

We must be very clear about the distinction.

What about correctness? Aren't throughput and correctness at odds? Shouldn't correctness be a purpose?

No. You are muddying the waters.

Incorrectness is feature incompleteness.

If your feature or your system is insufficiently correct, you have more work to do. It's that simple.

This is not mere semantics, by the way. Our perspective is skewed if we muddy our domain and our plan of attack will be confused.

So our problem, the real problem, the root problem, is throughput. How can we optimize our productivity? How can we deliver sufficiently correct capability at the highest rate?

In software construction this is the sole unit of optimization that should matter.

Any tool or process we endorse or espouse is valuable only inasmuch as it increases our productivity.

This is not a trivial optimization problem. But it's also not rocket science.

Whole-hog static typing¹?

—It helps correctness!

Nope, you're muddying things, try again. How will static typing make me more productive?

—Okay, fine, how's this: static typing slows things down today, yes, but speeds things up tomorrow—during, for example, next week's refactoring.

Great, you've got it now. Of course we have to make sure that the tomorrow's speedup you're talking about is greater than today's slowdown—amortized over time and all of that. And, furthermore, we have to ensure that this is the most optimal way to achieve next week's refactoring.

But at least we're speaking a shared language now. At least we're optimizing for the right thing.

Every advocate for this or that software tool or language or process should be held to this standard.

How are you going to increase my throughput?

Footnotes

  1. Whole-hog static typing is the form static typing most commonly takes. Most if not all mainstream statically typed languages do not offer first-class opt-out/opt-in to the type system. They force you to leverage the type prover across the board or use clumsy, second-class syntax to opt out of it.