Scaling down 'Agile'
The word 'Agile' has been a buzzword in software development for over a decade now. But the name confuses, well, pretty much everyone. Even the first page of its Wikipedia article isn't going to win any plain English awards.
The first problem I had when introduced to the term, was that in my head, 'Agile' meant the same as 'Quick'. In fact Agile can be anything but quick. It can feel frustratingly slow to people, like myself, who just want to get on with stuff.
The point is that Agile is built to factor in the ever changing needs of the customer without the development team wasting time writing software that just isn't needed. Perhaps 'Nimble Programming' would have been a better term.
From a practical point of view Agile programming has meant Scrums (no plain English awards here either), Kanban and unit testing. In a small team, Scrum gets reduced to a daily chat. Kanban relies on the customer being trained in the concept so unless many developers are working with many customers on one project, this doesn't really come into play. At Coracle, we have a direct link between talking to our customers and the resultant development. This works well. All features get developed, nothing gets lost, and no time is wasted on grandiose procedures that aren't needed.
That leaves unit testing. This was a notion I fought hard against when I was introduced to it. It's counter-intuitive to the developer who has been hacking for years. But strangely, as soon as I started at Coracle, I realised that it was something I was going to take on board.
The problem with unit testing is that the theory and the practice don't sit well together. In theory, each function in your code should be covered by at least one test function, with "100% coverage". Furthermore, there should be a series of integration tests covering the broad behaviour of the code from the user's point of view.
In practice we have to write software to deadlines. And the quickest way to meet a deadline often feels like writing no tests at all.
So where's the balance? Once I got my head out of the theory books and into the real world, I thankfully found out that the balance is struck by this nicely simple statement "Use your common sense" (or perhaps that should that be 'Steve used his common sense' for the Learning Line generation).
I really like Django's test framework. It sits on Python's mature testing framework, that caters nicely for the Agile Evangelists among us, but offers a practical, "some testing is definitely better than none" approach. You can quickly write a suite of functions that mocks up the hitting of web pages without reams of mocking code, enabling you to quickly write 15-20 tests, covering the broad behaviour of your site without banging your head against the desk.
Let's face it, while mocking sounds good in principle, the reality is always a bit grim. It works, but it's not pretty to look at.
Just that alone means you sleep better at night knowing that if you need to make a quick deployment, the passing of those 15 to 20 tests on the server will give you a good idea that you've not broken anything. Especially when scrabbling to do that deployment at 17:30 on a Friday.
Welcome to 'Nimble Programming'. I'll talk more about it soon.