Clojure Gazette 173: Dealers of Abstraction

Written by Eric Normand. Published: May 16, 2016.

Eric Normand's Newsletter

Software design, functional programming, and software engineering practices

Over 5,000 subscribers

Dealers of Abstraction

Clojure
Gazette

Issue 173 - May 16, 2016

Read more about this week's sponsor, Arachne , at the end of this letter.

Hi Clojurists,

What unites programmers across all languages and paradigms is that we all deal in abstractions. We are constantly discovering abstractions, creating abstractions, and encoding abstractions into our software. It's what we do. It's our job.

Yet abstractions are often wrong. We work all day building some software, only to find it has many bugs. Did the abstraction not fit the problem? Was the problem not well defined? Or perhaps we wrote the abstraction incorrectly. Bugs, bugs, bugs.

I would bet that most of our abstractions are "incorrect" in some way. Either they have a bug, or they're not performant enough, or they don't solve the problem, or it's not actually what they wanted (even though it's what they said). I actually think that the number of incorrect abstractions is about ten times the number of correct abstractions. Of course I don't have hard numbers, but it's got to be a lot. How many times do we modify code to fix a bug?

So most of our abstractions are wrong? And that's our job? No wonder we've had a "software crisis" since the 1960s.

Building an abstraction into our software is like betting that the abstraction is correct. A bigger abstraction (measured in lines of code) is a bigger bet than a smaller abstraction. More lines of code means it's more likely to be incorrect. And remember, many bugs are not a problem with coding. The idea behind the code might have been wrong.

If we are getting abstractions wrong and bigger abstractions are a bigger risk, the answer is obvious: we should write smaller abstractions. Smaller abstractions are each less risky. Each is more likely to cor rectly solve the problem it is trying to solve. And that problem is more likely to be at least useful, if not exactly what is needed. Correct and useful mean reusable.

Smaller abstractions are also cheaper to write and throw away. So the investment is smaller if it turns out they are incorrect.

More reusable and cheaper to write? This sounds like the holy grail of software engineering. It would have serious consequences for the cost of software if it's true. I happen to think it is true. So why are we not writing little-bitty, one- and two-line functions? Are there other factors at play? I'll be exploring this in the next several issues.

Rock on!

PS Please check out the sponsor. The Arachne Kickstarter has reached its goal but could still hit some important stretch goals.
PPS Want to get this in your email? Subscribe !
PPPS Want to advertise to smart and talented Clojure devs ?

Sponsor: Arachne

Congratulation to Arachne for reaching the funding goal on Kickstarter . There is still a very important stretch goal, namely "Deployment and Polishing" that is very close. Your pledge might push it over the edge. There are still a few hours left to go. Please back the project if you'd like to build production apps in minutes, not months. Also, congratulate Luke VanderHart on the successful campaign. The hard part of actually building the thing is up ahead.