Build and Fix -> Discover, Build and Clean

When I started working for a software house our work was mostly made up of building and fixing, we were told what to build, didn’t do it very well and spent most of our time fixing it. If we delivered, it often turned out to be the wrong thing, but we left it there just in case, making future development harder. Fixing systematic issues was ignored in favor of fire-fighting, there was no time for improvement. Today our daily activities are a bit different so I thought I’d try to break them down

So what is it we do:

Discover

We spend most of our time in a state of discovery, this happens through conversations with each other, stakeholders and users, but most of our discovery happens, if we let it, from the build and delivery.

Build

We do it early because it’s an important part of discovery and enables us to deliver. Building something useful is our purpose but we build in such a way that we can adapt our design as we discover better ways of doing it.

Clean

If we are free to build rapidly we need a clean environment to build on. Cleaning activities include refactoring, automation and general removal of problems: day-to-day, social or systematic.

Deliver

We deliver often because the feedback leads to discovery.

Fix

If we discover the right thing to build and our code and environment are clean there isn’t much to fix

So. What’s changed? A mindset that values discovery, brought about by the realisation that we cannot know till we try. Discovery happens naturally if you let it, we soon discover that keeping clean is more effective.

One comment

  1. Another thing that really helps avoiding the Fix stage is that in the Discovery phase we get the opportunity to question why something is required (and vice versa). This questioning process itself can lead to less complex solution and also leads to a much better understanding of the intention so we can write the right code.

    We used to write code to cater for all sorts of things that “users might want”, now we write code to satisfy what we know is required, avoiding unnecessary complexity that is costly to maintain, then enhance as we get feedback.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,058 other followers

%d bloggers like this: