Published: June 23, 2022 • Updated: May 04, 2023 • 2 min read
A naive implementation is a programming technique that prioritizes imperfect shortcuts for the sake of speed, simplicity, or lack of knowledge.
What is ‘naive’? Here’s the dictionary definition:
- marked by unaffected simplicity : ARTLESS, INGENUOUS
Let’s see it in a programming context!
A pangram is a sentence that contains all the letters of the alphabet, such as: “The quick brown fox jumps over the lazy dog.” Consider this problem I borrowed from Exercism, asking us to build a function that detects pangrams. We have written a failing test that describes our desired function.
class PangramTest < Minitest::Test # Empty string is not a pangram def test_empty_string refute Pangram.pangram?('') end end
Naive implementations don’t have to be test-driven, but it does help make the
point. What would be a naive implementation of the
pangram? method? It would
take lazy shortcuts. Here’s one:
class Pangram def self.pangram?(_) false end end
Looks silly! It doesn’t appear to detect pangrams at all, returning
any argument. Why would we bother to write code like this?
I don’t do this every time I code. But it’s a powerful technique for getting unstuck and shaking things up, for a few reasons.
First, this got us from zero to a working test, an unqualified victory. A lot
of code is not tested at all, if you can believe it! And, we aren’t solving the
problem of getting a test to run at the same time as we decide how
works. Our dumb green test here is what Adam Young would call “building from
success.” Let’s take that success and build from it!
Second, and stay with me here:
pangram? is not wrong… given what we
currently know. In a sense, it does detect pangram-ness, because the sentence
we’ve provided is not a pangram and it correctly identified that. We just
haven’t given it an actual pangram to consider.
Third, this technique ruthlessly exposes bad designs. Maybe we go through a
suite of assertions and find that we never had to improve upon this
implementation. This happens sometimes! We replace this function with a
false wherever it was intended to be called. Wouldn’t that be
nice? Our design was based on the assumption that people are going to need to
dynamically know if a sentence is a pangram, which was wrong.
Write a naive implementation, take the win, and earn your TDD stripes by proving that it isn’t good enough. Along the way, you’ll get a test that:
I learned this technique via Jim Weirich’s ‘Roman Numerals Kata’ live coding session at the Boston Ruby Meetup. It’s a masterclass. This video is hard to find online these days in an acceptable quality, so I thought I’d add my interpretation.
What are your thoughts on naive implementations? Let me know!
Join 100+ engineers who subscribe for advice, commentary, and technical deep-dives into the world of software.