I just received the physical edition of Dr. Dobbs, just in time for the weekend. This meant I actually could take time to read some of it.
I feel over one of the first articles and dug in, I skipped the editorial. I have however come to enjoy editorials since they sometimes are good at providing an overview of something which often sound completely uninteresting, to me.
Anyway I read the article 'Are You Immune to Test Infection' which was on developer testing. The author addresses the lack of the developer testing embrace.
He states that the future of developer testing can have 3 outcomes:
Poignant, yet true!
sometimes you are in a situation where developer testing simply is not possible due to time/budget constraints or other circumstances.
This is self-contradictory – the more critical and time-constrained a project, the more important good tests are! If you are short on time, you cannot afford to waste time debugging, and a habitual testing culture will massively reduce the time it takes you to narrow down problems.
It’s kinda like saying “we don’t have time to make backups.” Boy are you going to regret that if anything goes wrong. The risk situation with tests is unfortunately different, because failure to write any one test will not result in catastrophy, but unlike with with backups where you can go lucky for years, you will run into a problem that could have been avoided by writing tests. And another such problem. And another. And another. Ad nauseum.
Which is exactly the sort of risk structure that human brains fail to evaluate properly. (Cf. fears about aerial terrorism vs traffic accidents.)
You cannot afford not to write tests!
Re:Afford, or afford not to?
sigzero on 2007-07-09T16:04:40
First off, I agree. My only concern is that the "client" might not put that together and wonder why you aren't cranking out "code".
Re:Afford, or afford not to?
jonasbn on 2007-07-09T19:27:47
I agree, and do not get me wrong I do developer testing myself.
This however, in my opinion, is something which is culturally controlled. I must sometimes change context in terms of culture an adapt to client expectations, budget and other constraints, since I work as a freelancer. Many of my clients have no idea what software development is, so either they buy the idea or they shun the idea (often the latter judging from budget).
And yes I regret this every time.
Working as a freelancer, coming from a corporate development culture where there was space for unit-testing have taught me something else. When I started out I attempted to adapt corporate development culture (the good things) to my projects, but lets just say, the clients where not ready, some of them where not even ready to get development done in the first place and should have stuck to Excel or whatever they had before. Corporate development is a luxurious world compared to freelancing for small companies.
I have surpassed my share of deadlines and paid the price also financially - so today I do developer testing when there is room for it in sense of budget and time. I always make room for it in my estimates and with my estimates improving I get to do more developer testing in the projects I do.
Unfortunately I sometimes get caught in a situation where I have to do more projects in parallel then there is not much time left for doing developer testing - and when I outsource I do not always have the time to learn the resource how to do developer testing.
Often I get a product, back where I then have to look into developer testing, something I do not always have time for and there was a reason I outsourced it in the first place.
I also get assignments with corporations, but when you are hired in as a freelancer you are sometimes assigned to projects, which are run in departments that are under severe constraints and therefore the development culture does not have room for best practices, so you do the best you can with time given.
I still think of myself as new in this business and I can feel that things are improving, with everything from client relations, to estimating and coding using good practices, so perhaps in a few years perhaps I can afford the luxury of declining clients not ready to pay for proper development, not hire resources which do not do developer testing and code using best practices, but until then I must have pragmatic approach to developer testing and some of the other good practices, but believe me I am very much aware of this fact.
So yes, I think it something we should afford, instead of paying the penalty later.
Comparing developer testing to backup is a bit drastic in my opinion.Re:Afford, or afford not to?
Aristotle on 2007-07-09T23:47:42
Actually it’s exactly what I was talking about.
Yes, failing to make backups is a huge mistake. It results in a huge catastrophe at some point.
It may seem drastic to compare tests with it, but it’s not. The difference is simply that instead of a single big catastrophe you get many small setbacks. You waste a lot of time at a later stage of the project that you could have saved by going more slowly in the beginning. “Give me six hours to chop down a tree and I will spend the first four sharpening the axe,” Abraham Lincoln supposedly said.
I appreciate that clients do not understand that testing is important and why; but in my opinion, that merely means you make room for it in the estimation without telling them about it. You are supposed to be a professional; that means you are supposed to know what it takes to deliver quality work, and your professional judgement is what you get paid for. If the client’s judgement of your activity is poor, part of your job is not to let them interfere with – just like a carpenter would make a big fuss if you told him to use some of your own old office glue instead of the proper wood adhesive from his materials, because it’s cheaper. He may do it if you insist long enough, of course, but he’ll warn you loudly and at length about the poor quality of work you are forcing him to deliver. It’s his job to have better judgement than you.
So I see it with software professionals: don’t give the client choices that the client is not educated to make wisely. It’s your job to make the right choices for him to the extent that you can. Anything else is irresponsible. You said it yourself: you regret it every time.
(NB.: this is not criticism. I am trying to provide another angle to look at the matter.)
Re:Afford, or afford not to?
jonasbn on 2007-07-10T05:29:58
I do in no way take this is a criticism:)
Since what we are discussion are founded in matters of opinion and I rather enjoy discussing the topic.
Anyway I am going to have you have the last word, since your argument is very sensible and reasonable and I agree.
You actually used an argument I always use, when talking about whether you should be working on some semi-configured workstation provided by a client, instead of your own.
I always argue that you do no require either the plumber or carpenter to use your toolbox when they show up on site.
Thank you for commenting, I will attempt to be more professional in the future and let developer testing be a part of the work package every time.
It will take some time before this practice will be fully adopted, but being aware of this, can only help - and in the end quality will also improve. For the happiness of both client and developer.Re:Afford, or afford not to?
Aristotle on 2007-07-10T05:48:03
Yes, exactly. We’re fully in agreement.
And I know – it’s not going to be easy. But software development is in a terrible state right now, with hardly any projects finishing in the estimated time and budget and with satisfactory deliverables, and that won’t improve unless we as practicioners make conscious and conscientous efforts to change the situation.
Therefore: onward ho.
:-)
