Testing, Testing, 1.2.3.4.5.6..ad infinitum

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. 

Engineering, Not art/craft 

I often hear that software development is a craft or an art and that it is creative - this may well be the case for UI related disciplines but business software is the geography teacher of practices, boring and wearing tweed.    Once all the requirements are down and how these are going to be met are sorted  - that's it. Software is being driven out in a very prescriptive manner.  The biggest debates that happen in my team are not religious wars about coding standards - we have static code analysis, not religious wars about performance - we have resources to burn,  not religious wars about  general designs issues we have SOLID (and other guiding design guidelines), but no - we have wars about how we are going to test something and where.  ATDD brings this war right to the inception of a story/feature (sorry I often get these the wrong way around) and then we have a list of work todo and a checklist to say when its done.   This is all very organised and delivers value,  but I'd never realised how boring this actually is when you break it down. 

Summary

This might sound negative,  and boring is generally not considered good, but it is a matter or perspective.  Boring is good, as  I said before, for the business.   Now, I enjoy going to work and doing a good job, but I am wondering what it is I actually like doing anymore, maybe I have become boring and that's what I now like.  That's what my Mrs thinks anyway...

 


 

Comments

Post a Comment

Popular posts from this blog

SSDT March 2014 Static Code Analysis Extensibility

Static Code Paralysis. Coding standards (and more latterly styles) in any organisation of any size are liable to incite religious wars and makes zealots out of even the most considered or apathetic of us.   Inconsistency and subjectivity,  lack of enforcement and heavy handedness all contribute to the contempt often leveled at them.   Sod it. I say sod all that, if you or your company aren't using static analysis tools  then you are missing out on improved code quality and productivity (borne out from a consistent approach) and reducing the most banal and mind numbing conversations and sometimes pissing contests associated with discussing the minutiae of standards.   As an aside, having a few years under my belt  in the industry  I've found that people who "really" moan most about this are usually rabble-rousing morale sappers who like to moan about everything, so it stops them doing this and maybe might lead to them getting on w...
Read more

MongoDB

Mongolicious MongoDB training, provided by MongoDB themselves, was up for grabs recently, so I put my name in the hat to get a keener insight into MongoDB and NoSQL databases, having used them only a few occasions. The training was attended by a near 50/50 split of devs and DBAs and this led to some interesting debates and reactions.   Like lots of the stuff I've been introduced to/have started looking at recently (I am late to nearly every technology party there is) they (Mongo and NoSQL) have been around for a while and have become established as a viable alternative persistence solution to the likes of MSSQL.  The main features: Its schema less Document oriented/No support for JOINs  Querying performed using JS/JSON Indexing Replication/Redundancy/High availability Scaling out via Sharding  Aggregation (unfortunately we ran out of time so this is not covered here) Authorisation (again ran out of time on this one)  ...
Read more

DDD or not to DDD? That may or may not be the question.

DDD I've had/am involved with my first commercial experience of DDD, or at the very least, something heading that way. My team are developing their first DDD software component.  I didn't realise I was at least 10 years behind the leading edge ( the year  which Eric Evans seminal work DDD was published was the same year I started my career as an embedded software developer, which is as close to enterprise development as Pluto is to the Sun)    DDD Quickly After being in a few larger organizations and having dealt with a fair few types of design approaches (ranging from monolithic to typical n-tier), it seems  that DDD has finally achieved mainstream adoption in the industry and the shit kickers - I include myself here -  are just about ready to consume it, and murder it potentially :)  I have read "DDD quickly" on InfoQ, which I would highly recommend to get a flavour for DDD in general, and have recently started reading  "Impl...
Read more