Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

jonasbn (1153)

  reversethis-{gro.napc} {ta} {nbsanoj}
AOL IM: BJonasN (Add Buddy, Send Message)

Perl Programmer located in Copenhagen, Denmark. Active member of Copenhagen Perl Mongers.

Author of:

  • Business::DK::CPR
  • Business::DK::CVR
  • Business::DK::PO
  • Business::OnlinePayment::CashCow
  • Date::Holidays
  • Date::Holidays::Abstract
  • Date::Holidays::Super
  • Date::Pregnancy
  • Games::Bingo
  • Games::Bingo::Bot
  • Games::Bingo::Print
  • Module::Info::File
  • Module::Template::Setup
  • Test::Timer

and maintainer of:

  • Tie::Tools
  • XML::Conf
  • Workflow

Journal of jonasbn (1153)

Monday July 09, 2007
07:35 AM

'Are You Immune to Test Infection', no but I am busy

[ #33757 ]

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:

  • Long-term defeat, developer testing dies
  • Small victory, used be certain groups and organizations
  • Major victory, developer testing becomes a standard practice

How he expect this outcome to manifest itself and when is somewhat unclear.

So I read the article a sort of call to arms.

He described the problem as being rooted in the developers - and I agree to some extent. He then go on to dividing the developers into 3 groups, based on genetics, outlining 3 developer profiles and their respective possible adaptation of developer test.

  • T1 gene - developers which embrace developer testing
  • T2 gene - developers which embrace developer testing with some time and encouragement
  • T3 gene - developers immune to developer testing

For one I do not like the gene analogy, I am no biologist and eventhough genes might have something to say. I see the test adaption very much as a cultural problem.

The author makes an important point of managers and senior developers should use their influcence to get developer testing applied in their organizations, when climbing the career ladders.

I think this is good, formal requirements for developer testing is good.

But - I need to wrap this up.

I do not regard developer testing as a on-going revolution, developer testing has existed for a long time. With unit-testing and practices like test first development and the whole agile movement, developer testing has gotten a wider audience and much focus, all good things, but people have tested software since the first program was written.

Developer testing is here to stay and I believe in a state, that could translate to the author's 'small victory' - yes we have a lot of stubborn organizations, managers etc. who do not see the benefits of developer testing - and we have a lot of developers, who do not use developer testing. But this does not necessarily make them bad programmers.

Developer testing is good, we can agree on that, but sometimes you are in a situation where developer testing simply is not possible due to time/budget constraints or other circumstances.

The practices of software development mostly live in a sphere where it is under control from some other dynamics, primarily the dynamics of market economy. Economic analysis of developer testing, will probably fall out to the benefit of developer testing in the long run, but sometimes we are in situations where TTM is more important and ROI is rooted in the TTM so JFDI is the way to go.

To get back to the 'Small Victory'. I imagine that developers are using developer testing when and where feasible based on many perspectives and personal judgment.

Perhaps not even controlled by managers, budgets or deadlines - but whether the developer in question has the time and overview to tackle the task/project at hand using developer testing as a practice.

I use developer testing with my CPAN modules. There are no budgets, no deadlines and I can take my time to do this sort of work.

I use developer testing on client projects to the extent feasible, it is not a formal requirement so it is very much up to me to adapt to the assignment, so I use developer testing for my own benefit, economically and professionally.

I only use developer testing in bug-fixing when I have the time and often bugs are fixed and changes applied in a more hackish manner, because JFDI is the way to go.

I would love to invite the author for a visit to the Perl community, I am sure he we would be impressed over a hacker community like this, which use developer testing in to an extend that would wet the pants on these test evangelists.

And I very much regard the Perl Community as a pragmatically driven group, that simply live by the mantra TIMTOWTDI.

One last word on the article; if you want to sell something, even an idea, do NOT compare it to a disease, no matter how good the resemblance is.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • One last word on the article; if you want to sell something, even an idea, do NOT compare it to a disease, no matter how good the resemblance is.

    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.”

    • 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".

      • 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 corpora
        • 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 s

          • 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
            • 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. :-)