What I learned from teaching others

Last week I spent my time in a hotel teaching a group of apprentices on behalf of Cornwall College. This is a long term course on software development, with the aim of bringing these learners up to the level of professional developers for the benefit of themselves and their employers.

Last week we covered Software Development Methodologies, from the classic methodologies of Waterfall, V-Model and Iterative development, through the rise of Agile in the early 2000’s to today.

I taught a combination of traditional lectures and interactive workshops, of which the latter was infinitely preferred by the cohort.

Working day-to-day in an Agile company, I found revising all of the old methodologies quite interesting. There is many lifetimes of research and experience shared around the world when it comes to building quality software, and it was good to be reminded of a few techniques we don’t use here, that may be useful again one day.

The students decision at the end of the week was that traditional methodologies are too much overhead and that Agile is a better approach because you get working software more quickly. Even in our simple classroom examples, getting specific requirements nailed down without ambiguity proved impossible. With Agile, as soon as we had some even partially working software, the initial requirements started to solidify and clarify much more easily.

Whilst I agree with their instincts, my experience working with different companies throughout my career made my main takeaway from the week slightly more nuanced.

The Agile manifesto was written as follows:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

I have found that Agile is a great way to cut time to market, cut through red-tape and deliver solid software, but too many companies and indivduals use the practice as an excuse to do away completely with the items on the right. Waterfall and similar software methodologies generate so much paperwork and documentation that costs can’t help ut be inflated, however not everything needs to be thrown out. Some documentation is genuinely beneficial and some processes can streamline instead of choke up the workloads. The real key is balance between left and right, and that balance may shift dramatically per project.

Agile should be about removing dogmatic adherence to processes, finding what works for your project and applying those findings. Not as an excuse to do less paperwork!