Saturday, 31 October 2015

Python Weekly # 3 : Incremental development

Incremental Development

or how a long journey should start with a single step

Unlike most of the other articles in this blog,  this article really isn't about python, but the language does lend itself to this style of project.

When you start a software project, it is very easy to dive straight in and start coding - with a good idea of the end goal, but maybe with not much of an idea of how you get from a empty file to the final application. I have made exactly that mistake myself - and my Development folder is littered with half started "big" projects.

It is much more efficient to take small steps, coding, testing, debugging and then repeating until finished. This is Incremental Development, and there are a few good reasons why it works - and works well :
  • You know that each step works - so when you start your next step you are not introducing bugs on top of bugs.
  • You might well surprise yourself and finish early - as you realise you get to point where your application is good enough, and you don't need all the bells and whistle you thought you might need.
  • You get a powerful sense of achievement - each cycle you know your code works and you are one more step along your journey - a bit like seeing distance markers on a highway.
With Incremental Development you follow a few simple rules :
  • Your cycle (design, code, test, debug) should be no more than a couple of weeks long - and if possible even shorter.
  • Target a small number of features on each cycle - maybe only one or two features to begin with.
  • Start your cycle by working out how you will test your feature - and if you can start by writing your test cases first.
  • At the end of the cycle - make sure your latest working code is saved in some form - so if the next cycles goes horribly wrong - you can always go back. The best way to do this is to use a formal change control tool such as git, mercurial or subversion.
  • Within your cycle complete one feature before you do the next one - that way you have progress made even if the 2nd feature doesn't complete.
  • If a feature proves too complex,  drop it from the cycle - and take time to refine the design or split it up by redesigning it in a brand new cycle.
The key to this process is the concept of a feature, which is best defined as follows :
  • A single piece of  functionality which can be described by a simple sentence. One thing your software will do in order to achieve the whole aim.
This is best explained by an example :

One of my first home projects was an application to upload one or more images to flickr. To achieve this the application need to do a number of things including :
  • Connect to a flickr account
  • Get a list of Sets from flickr (a set is a group of images)
  • Upload a image to flickr
  • Add an image to a set
  • Record an optional title for the image
  • and many more (as you might imagine)
The application also included a GUI which needed to be developed which included a number of different elements.

Any one of those bullet points (and any one of the GUI elements) could be described as a "feature" - don't treat the GUI as a single feature - even with very good design tools, GUIs can be very complex, and maybe could be left to last.

Don't be tempted to make your features too complicated; if a features seems too easy (for example recording a title against an image) you will be able to develop more than one feature in a cycle. If you start trying to combine items and call the combination a feature - you run risk of something being far more complex, and you end up with a bigger failed feature.

Language features in python such as classes, modules and packages make it very easy to practise this style of development. Many features can be added as either new methods or new classes and since the language itself does not have a complex syntax which requires a lot of extra punctuation, it is relatively painless to write new code quickly. The python interpreter is also a massive benefit - giving you the change to test new code quickly, even without full test scripts.

To summarise - start slowly in small steps, and test as you go along - don't try to do everything at once. Don't be afraid to go backwards.

No comments:

Post a Comment