Test and Test Again

There has been some discussion of the application of agile principles including test driven development in the office recently. Having been working on a highly concurrent, scalable SIP application server my feet are firmly in the test first, test often camp.

Our testing strategy includes:

* unit testing, usually using mocks and dependency injection
* acceptance testing, using FitNesse
* robustness testing, using custom scenario handlers
* performance testing

These practices are dependent on the type of project, but we've found that although unit testing is done before the functional code is written, the other tests are usually written afterwards. I like to think that acceptance tests demonstrate completed user stories and robustness tests exercise common scenarios, concurrently.

A robust application comes with time, but through concurrent testing, issues can be drawn out earlier and the confidence you have in your application grows.

Becoming a Software Engineer

I was recently asked by a former disertation tutor to do a talk at my old university on being a software engineer at an open day for prospective university students. I was happy to oblige, and I've put up the slides on slideshare.net. However, in true Downey form there's not much in terms in written text, but there's more pictures and hopefully, engagement with the audience by the presenter.

This led to some interesting debates on my return to work, with some questioning the need to do a computer science degree at all. It seems there are plenty of people with other technical degrees that move into the software field, and seem to do rather well for themselves.

My take is that my degree was very vocational, and the things I learn't at university I apply directly to my job today. Also that I picked up a lot of theory and hopefully have a more rounded and thorough understanding of the technical problems we face. Hopefully. I have to say though that probably for each useful module I had, I had one useless module. Go figure, I could have tried harder at university, I could have learn't more, but I came out with a good degree and have a good job so no massive loss.

On reflection, a lot of the books I bought at uni are either sitting on my shelf largely unread or have been sold on eBay. But now adays I tend to read a lot of technical and 'business' books, so what would I recomend to prospective students?

'Technical books'

Agile web development with Rails - an excellent introduction to web programming in a cool language, though it leaves testing a little late.


'Business books'

Mavericks at work - a look at innovative solutions to common business problems.
Cluetrain Manifesto - how the web has changed business and made us communicate again.
Getting Real - 37 Signals answer to bloatware.

'Methodology books'

Practices of an agile developer - excellent practices to follow for an agile developer
Lean Software Development - lean and trim software development.

There's probably a whole bunch more I can't think/remember of and a bunch I'd like to read.

What would you recomend?

Software engineers need love too.

It's amazing how a new environment, a ton of pressure and a bunch of uncertainty can make people react. I found out earlier this week how software engineers react. At a three day off site, a large group of people, both developers and 'suits', were told to leave their job titles at the door. Unfortunately for me and the team I was working with, it felt as if we'd left our software engineering principles at the door too.

Having essentially 48 hours to build a product, mostly from scratch, or at least using new products/APIs and services to plug something together seemed to suggest that we threw our best practices out of the window. Now the working environment wasn't set up exactly how we would have liked it, but we could have done something about that. Without even the basic necessity of source control, it felt as if the team were fire fighting from an early stage with USB drives being swapped around at crucial times, along with cries of "hey, can you add this method to the code?" when it could have been done easily and checked in.

I certainly felt like I was developing with one hand without using test driven development, source control, continuous integration et al. If three days being thrown into the deep end has taught me anything, its to be prepared.

I once heard the phrase, "a bad tradesman blames his tools", but conversely, does that mean that a tradesman is only as good as the tools he uses? Perhaps I've grown so used to the tools that I use that I've come to depend on them, and while that encourages best behaviour, does that make me inflexible?