The ultimately agile, agile methodology… software development based on my whims and musings…
These days, most software engineers will be using Agile processes such as Scrum for developing software. These have helped move the software industry away from a World of big up up front designs, heavy documentation and rigid processes towards a more fluid place where change is embraced and designs are emergent….
To support this more flexible approach, an environment that was more supportive of code re-factoring needed to be in place so the changing requirements could be coded into the system reliably. The important word there of course, being “reliably” – the engineers needed to be sure that the changes they were introducing actually worked and certainly didn’t break existing functionality. This is where Test Driven Development (TDD) stepped in. By following 3 simple rules, everyone can be fairly sure that the software will be working, testable and decoupled…
The 3 rules of Test Driven Development
-
You are not allowed to write any production code unless it is to make a failing unit test pass.
-
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
-
You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
This continual cycle of “red-green-refactor” ie write a failing test (red), write code to make the test pass (green) and then restructure the code without changing the behaviour [Eg to make it cleaner] (re-factor) ensured incremental steps towards a fully testable and focused piece of software…focused that is, on making the tests pass.
As the software is focused on making the tests pass, then the tests could effectively become the requirements for the system. For that to happen, the tests had to be less about describing technical issues and more about describing the required business behaviour. This gave rise to Behaviour Driven Development (BDD) – which encompasses TDD but pushes it a bit further by focusing on the expected behaviour of a system / process rather than the implementation.
Much of this is semantics, but by following the recommendations, you do end up with a domain specific language that everyone can understand and use together Eg Analysts write stories with the product owners, engineers implement the stories, testers can help define the acceptance criteria etc. This can even lead towards the so called “Executable spec” whereby the requirements for a system consists of a series of clearly worded statements that can be run against the actual code they describe.
There are many derivatives from these styles including serious ones such as Acceptance Test Driven Development (whereby acceptance tests drive the unit tests) and less serious ones like Asshole Driven Development (whereby the biggest jerk makes all the big decisions) and to these, I’d like to add my own: Whim Driven Development.
The “x-driven-development” methods I’ve spoken about all provide a firm basis on which to start creating software and fit nicely into corporate/team environments where agile practices such as user stories and iterations are in place.
But what should I use for personal projects and for messing around?
For these circumstances:
-
I want to have a thought or musing and no matter how peculiar it is, I want it to provide the starting point for my system.
-
This initial thought is liable to change on a whim as are any assumptions made or implications derived from it.
-
I won’t be adhering to any notion of sprints / iterations, in fact, there are no deadlines or time boxes of any sort.
So WDD will need a way of recording my whims and then managing them through to working software. It will also need to be flexible enough to handle significant changes both in terms of functional whims and technical whims.
To achieve this, I’m advising a Kanban based approach so that a collection of whims is kept prioritised in my backlog, from the backlog I’ll move the top 3 to “to do” and size them. From “To Do”, I’ll move 1 at a time through “Work In Progress” whilst I work on it and then to “Done” when it’s complete.
The Whims will act like user stories and the whim’s acceptance criteria will give rise to functional tests, which will spawn the need for many unit tests which in turn will lead to actual implementation code. My process will be:
-
Write a whim, prioritise and add to backlog
-
Size the top priority whim and add to “To Do”
-
Take the top priority “To Do” whim and convert into 1 or more whim tests
-
For each whim test, generate enough code to make it compile
-
Write unit tests to cover the behaviour of the classes that were generated by the whim tests
-
Once the unit tests pass, ensure the whim tests pass. If they’re not, then write more unit tests until the whim tests pass
-
Move the whim to “Done”
-
Pick up the next prioritised whim
Obviously, there’s no indication of time scales here, whim’s take as long as they need to to get from “To Do” to “Done” – but throughout that time the software is kept “ready to deploy” as all tests must be in a passing state at all times.
A standard set of good practices – such as running all the tests as part of a continuous integration (Eg Jenkins), code quality analysis (Eg SonarQube) and managing my whims using a Kanban Board Eg (Eg Trello) should be adhered to too.