The Feedback Loop

As you can probably tell, I’m not a big fan of “framework-first” development, but I haven’t really been able to give a solid reason why. Inspired mostly by this article, “Why Software Development Methodologies Suck”, I think I’ve figured it out – the feedback loop.

The feedback loop is one of the most common-sense things that has come out of the Agile movement, most notably eXtreme Programming. One of the main tenants of XP is to reduce the feedback loop to as short of a cycle as possible in order to speed up software development. XP uses techniques such as test-driven development, iterations, small releases, spikes, and others to ensure that the amount of time for developers to get feedback on their code is as small as possible. Contrast this to traditional waterfall techniques where the time between requirements gathering and implementation is so great that one often didn’t have anything to do with the other.

It’s fairly obvious why a smaller feedback loop is better than a larger one. It’s easier for a software developer to make changes to a system that they’ve recently worked on, rather than something they wrote 3 months ago. So why is it that, when some teams go to create large projects, they spend so much time on the foundation without making the actual project?

Acceptance Criteria

A project’s requirements, as well as its success, is defined by a set of criteria specified by an end user. For user-facing apps, the end user is the one who determines whether your application is complete. For an API, other developers determine whether your API is complete. For an automated tool, the quality of output (usually verified by acceptance tests or some sort of user-facing report) determines whether your tool is complete. The shortest route to determine success is getting something in the end users’ hands.

So it confuses me when teams, when faced with a large project, start by spending so much time on the infrastructure and back-end systems that do not provide them with any sort of feedback loop. Why wouldn’t you start on the “happy path” or the “minimum viable product”, something you can actually show an end user? The end user doesn’t care what database technology you’re using, or how you’re migrating data between different sources. They care that when they click that button, or make that API call, something happens. You can’t actually prove that the work you’ve done to date addresses any requirements or has any value until the user says so.

The Happy Path

The happy path is the quickest way to get that user acceptance. And in reality, that user acceptance is all that matters – it is the thing that decides whether the work you’ve done is actually usable or not. So as a software developer, would you rather the user tell you the last two weeks of work you’ve done is wrong, or the last two months? Or two years? Which scenario is easier to fix?

All those other important decisions, all the infrastructure and back-end code, should all be derived from the happy path anyways. You should be asking yourself “what’s the minimum amount of work I have to do to make this happen?” Writing any code that doesn’t address that question is useless. This idea is something that’s ingrained in Test Driven Development – write only the code you need to make your test pass. Nothing more.

Sure, maybe some day your end user will want to perform task X. But if you code functionality for it now, you’ve not only wasted resources on something that isn’t an actual requirement, but also have created code that will probably be out of date if/when the actual user requirement is determined. You’ve written something that is based on made up requirements, that you won’t actually be able to verify until that functionality is exposed to the user, and I can guarantee you by the time it gets into their hands it won’t be correct.