I was recently reminded of an excellent post from back in 2009 by Brent Simmons called Anatomy of a Feature. In it, Brent walks through the seemingly trivial work required to add a “Save to Instapaper” feature to NetNewsWire. What seems at first like a simple call to a web service quickly expands into a number of non-trivial feature decisions that have to be made:
“Oh, it’s easy, just a quick http call. I could write a script to do it in like 20 seconds.”
But of course it’s not as simple as just writing a quick script. It’s tempting to think that adding a feature like this is just about adding the functionality — but there’s a bunch more to it than that.
So often people fail to grasp the inherent complexity of building software. In my line of work I often hear people talk about how easy it would be to throw in this or that feature with no regard to all the baggage that goes along with it. There’s very little intuitive understanding that software can be infinitely complex, that complexity is absolute poison to a software project, and that effective management of complexity is one of the key responsibilities of any project team. Even seemingly simple features can have implications that are far reaching.
Brent’s post is a really good examination of this issue viewed through the lens of a feature most software engineers can understand instinctively. It’s and worth a read if you work in or near software in any capacity, even if you’ve read it in the past. It’s a key principle that isn’t called explicitly out enough, yet it underlies so much of what we all do as part of software teams.