Before testing...I've now been in development/engineering/coding/hacking or whatever you want to call it for more than 10 years. Testing has always been important, but it - in my line of work - is now at the forefront of everything I do.
For the business this is great, every line of code, component and group of components is covered by some set of tests. Be it unit, integration, component...the overloaded terms go on. This means that a set of requirements - to some degree - have been determined to have been met by these tests and the business is getting what it wants (all manner of development and agile practices not withstanding - they all get us to the same place)
It struck me today though that earlier in my career, when testing was still important but lines were - perhaps - a little more blurred and things were a bit more hit and miss, things were less clinical, less contrived and quite frankly less boring. This is obviously not a good model for delivering quality software everytime but sometimes I yearn to literally hack out some code, build it and just experiment when things aren't working quite right. Yes this can be done guided by tests and within the confines of the TDD cycle but, for me, having not come from a TDD beginning, feels a little stifiling if I was developing a hobby project (not something I was contributing to on GIT) I, dare I say it, would not necessarily use TDD - but make no mistake, at this time, developing quality software for my employers I would not develop without TDD, it gives me confidence I never had in the past. Boring yes, Confidence inspiring yes.
This kind of work is left now for spiking or hobby projects, but it feels that, and although this term is bandied around, software engineering really is coming of age.