Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
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. :-)