Sometimes the comments on this blog are better that the articles themselves. I've elevated one of Sean's comments to a full "guest" article a while back: "An Architect's View: Sean's feedback on my recent article about ColdFusion interfaces", and over the weekend my mate Simon put his oar in on one of my recent Unit Testing / TDD articles to feedback some useful info to one of my other regular commenters, Bruce. What Simon says is very true, and something I think all devs should bear in mind. It's got nothing to do with testing or TDD, but is all about how we ought to be approaching our work, as professionals. Simon's comment:
Bruce,I was going to include some context, but I think it speaks for itself.
sadly this is incredibly shortsighted and naive. Only fulfilling business requirements is akin to building a house on sand. Time to market is great but eventually your weak foundation will remove all your competitive agility.
As a software engineer (I deliberately use this term over developer as I see what we do as an engineering function) we have a responsibility to fulfil our product owner's vision. However, we must own how that is achieved. We are the experts in how, they are the experts in what. This means version control is a must, any code base not in version control means someone should be losing their job. It's is free, easy to use and just insanity to avoid. This also means using all the techniques available to you to avoid failing. TDD is really a design technique where unit tests are a happy byproduct. Your tests the first client of your code. You then satisfy your client. Then you decide if you as the engineer are satisfied with the design. If not then at this point you can refactor knowing that if your tests pass your client is still satisfied.
To summarise, I would never accept a client stipulating how something should be done, they should just indicate what they need.
Obviously you need to put yourself into their shoes and understand their needs as this is supposed to be a collaborative process. Being difficult is not what I am advocating, but doing exactly what you are asked for is not always giving them what they need.
Simon makes a very good point, and one that I completely agree with, and it's an approach to our work we should all take. My position is that I've been hired for my expertise, not simply as a drone to do the typing for my employer whilst they dictate how the work should be done. Fortunately my employer seems to see it the same way. And this is the way the work environment ought to operate. Unfortunately too many managers think they know best, or think that "leading" is "doing", or "dictating how things should be done". What a manager should be doing is managing the "what" side of a requirement, and enabling the developers/engineers/programmers busy themselves with the "how". This should extend to what tools the dev needs to fulfil the "how", and the general architectural approach.
As teams get bigger - at my current gig there's around 40 (? dunno... haven't counted recently) bods in the IT dept, and about 20 of those are developers - there's need for stratification within the ranks, and the person at the bottom of the food chain is not making overall architectural decisions. This task has been delegated upwards to a technical architect (which in this case happens to be Simon ;-). There's a case for "too many cooks" in situations like this. However everyone from top to bottom has input into how the work around their "strata" of the process gets done. Ultimately we all aim for what we consider to be best practices. And, honestly, this is encouraged in both directions from top to bottom. Which is cool.
I'm privileged to be in a pretty good team where the decision-makers know that "best practices" are labelled that way for a reason. However I realise that not everyone is lucky enough to have this. This doesn't mean you backslide and start taking the Nuremberg Defence for the quality (or lack thereof) in your work. If you're a contractor you've been hired for your expertise in your area... otherwise you'd not be demanding the high rates. If you're - like me - a senior developer - then your job title comes with the burden to offer advice upwards as well as downwards in the foodchain. If you're further down the foodchain, you should not take a drone mentality, you should still get yourself into a position where you can have an informed position on the work you do, and still work at making any improvements you can. This his how you move up the food chain for one thing.
So don't sit back and go "[shrug] I'd love to follow process but I can't". Make them change. It's your job to. Or, perhaps, decline to do the work. Make them know you're serious about it.
Anyway, I'll step out of the pulpit and back down to my desk to crack on with work. Lunchtime's almost up.
Cheers for your comments Simon. Great stuff.
--
Adam
