the simplest thing that could possibly work -- it's a phrase held dearly to all agile developers, but it's also a common source of disagreement. I recently saw two different interpretations of the phrase that I considered to be worth sharing.
Often the emphasis of the phrase is like so: the simplest thing that could possibly work. However, recently Ian Robinson was discussing the idea that the emphasis should be: the simplest thing that could possibly work. The difference is only emphasis, but it's a change worth considering.
I was also part of a discussion the other day where a developer was following a pattern correctly, but it was causing us to add a significant amount of additional code. This code would have supported several features that seemed nice to us, but our domain expert hadn't asked for any of those features. I would have been happy to go along if there was a small amount of code or if the nice features were on our roadmap, but neither of those things were true. I began to advocate for breaking the pattern and doing only what we needed to do. It allowed us to delete ~60% of the code we were currently working with.
At first the developer said "this is where we're going to disagree on the simplest thing that could possibly work." He argued that we were backing ourselves into a corner by not following the pattern; therefore, what I was suggesting couldn't possibly work. I took a few moments to consider his point of view. I concluded that he might be right, but deleting 60% of the code we were currently working with meant that the remaining 40% was so small that if we did need to rewrite in the future it would actually be easier than the amount of effort required to maintain the prematurely put in place architecture.
I believe there are occasions where the simplest thing that could possibly work is writing 10 lines of code today that do what you need, and deleting them tomorrow in light of new requirements.
There are, of course, a few caveats. I had been pairing with the developer for about 4 hours and was able to accurately assess what the difference actually was between what we were doing and what we could be doing. Once we both saw how much effort it was to follow the pattern, it was easy for us to trim to the simpler version. I think it would have been more painful to speculate on the pattern implementation effort, and we may not have agreed on the outcome.
Also, painting yourself into a corner when you can jump over the paint is fine, but if someone else keeps painting on the other side, you may not be able to get out. The small amount of code that we wrote can be rewritten in about an hour, but if someone else was going to add to that code then we would have probably gone down the more complicated path. No one was building on our code so we weren't as worried about the foundation we put in place.
interesting perspective on emphasis of words. I've thought the "simplest" part is open to opinion, but I never though of how "possibly" could be a matter of opinion. I guess it depends on perspective in planning.
ReplyDeleteI think its important to balance simplest and possibly. For me that means I focus a little more on "simple" because I tend to get the "possibly" right a little easier than some (I can tend to complicate things sometimes). The extra focus helps me balance the two and it tends to work out then.
Another aspect that I focus heavily on is "simplest for whom? The developer or the user?" In this context, user refers to the other developer that will use the API.
ReplyDeleteAs with all things, the right answer is a balance between the two approaches. However, assuming it's possible for me to support it, I usually side with what's simplest for the user.
You must have been talking to Ward!
ReplyDeleteI worked briefly with Ward Cunningham a couple of years ago, and we discussed "the simplest thing that could possibly work," and agreed it wasn't "the simplest thing that could possibly work", which is an almost aesthetic judgment about the "final" state of a system (but which may not display a duty of care to the overall lifetime of a system); rather, it's "the simplest thing that could possibly work." It's an investigative, exploratory tactic, to get you somewhere (we don't quite know what to do next, so let's do the simplest thing that could possibly work, and find out).
This is a place where YAGNI probably could've also been used to argue against the pattern.
ReplyDeleteThere's an excellent interview with Ward Cunningham on Artima.com, covering simplicity and complexity in software and the simplest thing that could possibly work
ReplyDeleteFrom the interview:
It was a question: "Given what we're trying to do now, what is the simplest thing that could possibly work?" In other words, let's focus on the goal. The goal right now is to make this routine do this thing. Let's not worry about what somebody reading the code tomorrow is going to think. Let's not worry about whether it's efficient. Let's not even worry about whether it will work. Let's just write the simplest thing that could possibly work.
Great post, Jay.
ReplyDeleteI've often struggled with this when pairing. It's such a difficult thing to talk someone out of removing code when their argument is, 'Well, in the future we're going to do this, because I know the customer will want it.'
Bryan,
ReplyDeleteI definitely feel your pain. These days I like to talk about speculative generality (from Refactoring) with the team in abstract terms. If you get people to agree in the abstract sense, it's the first step to getting them to agree on actual code.
I also tend to pull someone else into the conversation so it's not a 1 on 1 battle between a pair. Instead, I get someone else involved to break the "tie". I generally grab the smartest person in the room, whether I think they will side with me or not. If they also want to go with a speculatively general architecture, I move on but make a mental bookmark. Generally the choice causes enough pain that we end up going the simpler route at some point anyway.
Thanks for the kind words and the comment.
Cheers, Jay
I guess it all depends on the road map. Planning for something you are never gonna do is useless. On the other hand re-writing everything when the requirements change a bit is painful and slow. Unfortunately I started to see implementations of agile methodologies that are anything but agile. I expressed my frustration in a post if you are interested: The Agile 800 Pounds Gorilla
ReplyDeleteOne hour of coding is not a big deal but if these things start to ad up and you have hundreds or thousands of things implemented in the simplest way you might end up with no architecture at all.
Interesting post, good for stirring thought.
Cheers,
Daniel
I agree to a certain extent, the problems I've have arise when someone else comes upon your coding job, familiar with the way things are done, and doesn't know what happened. If your code is supposed to have some feature it doesn't need today, maybe tomorrow someone will fold your code in with a bunch of others that do have the extra functionality and run into problems with your slightly lacking problem.
ReplyDelete