The four goals every project should aspire to have

June 28, 2013 Robbie Clutton

I did a presentation recently at NYU for their Summer Launchpad programme where I talked about prototyping and agile development. There was one slide I touched upon in the talk that I wanted to expand upon here, and the topic was on the four goals every project should aspire to have. They are:

  • Features that have hypothesis
  • Hypotheses that can be easily validated
  • Code that is always production ready
  • Code that is easy to change

Why do I think this is important? Features that have hypotheses associated to them have gone through a thought process that believes something in the application will be improved. That may be experience, revenue or other performance indicators for an application. This will help focus the feature and enable suitable metrics to be extrapolated and used to falsify the hypothesis. Being easily validated means that the hypothesis and by the same nature, the feature is small. Small features mean the build-test-learn cycle can be shortened. Easily validated also means easily falsified, being that the team should not look for confirmation bias that the hypothesis was correct.

Code that is always production ready can imply some amount of housekeeping but I like to think it means going back to small features and small stories where each story is independent and adds value to the user. If that is the case, each commit can be a potential release candidate. Finally, code that is easy to change means two things. Firstly the code is designed so that any potential product change can rarely be a big technical change. This isn’t always attainable, but if features and stories are small no one story should change a codebase in a significant way. For me design also means evolutionary design through stories delivered combined with constant refactoring so that the codebase is always sensical.

Change also means confidence where confidence means tests. If a change is made to the codebase and no-tests fail that should mean that the code is production ready and if tests fail it means it is not production ready. If tests pass but the code is not production ready it either means that there is code coverage missing from the application.

All in all, these fairly simple goals have a lot going on in the background, but can push a project towards a heathy place.

About the Author

Robbie Clutton

Robbie Clutton is the Head of Pivotal Labs in EMEA.

A tmux and Vim Clojure IDE
A tmux and Vim Clojure IDE

I recently began experimenting with Clojure on a side project. Since Vim is my preferred editor, I’ve been ...

Deploying a Rails App to CloudFoundry
Deploying a Rails App to CloudFoundry

CloudFoundry has launched a private beta, and if you’re lucky enough to have access to it, you can get free...

SpringOne. Catch all the highlights

Watch now