Comments on: Falsehoods programmers believe about time - riff on the malleability of computer time

By: Adam Lopresto

Adam Lopresto — Wed, 20 Jun 2012 20:17:00 +0000

Or very relaxed values of =.

By: invictus

invictus — Wed, 20 Jun 2012 16:24:00 +0000

Now I have to silently wonder if your reply to my snarky comment on your snarky comment on the original comment was, in fact, snarky.

HelpI’mtrappedinarecusrivecommentthread!

By: Mitchell Hughes

Mitchell Hughes — Wed, 20 Jun 2012 15:54:00 +0000

Not true. In the Gregorian calendar, leap years occur every 4 years, unless the year is divisible by 100. Then it will not be a leap year. Unless the year is also divisible by 400. Then it will still be a leap year. The year 2000 was one of those.

By: Noah Sussman

Noah Sussman — Wed, 20 Jun 2012 14:52:00 +0000

It's extremely difficult to measure time saved by defensive practices like writing readable, tested code; this is a bit like trying to measure the number of attacks mitigated by good security. In any case, only large organizations are willing to spend the time and money to attempt to measure the effectiveness of code quality. One of the few decent studies I've seen is The Power of Ten by Gerard Holzmann from JPL/NASA. Also there's a new book called "How Google Tests Software." I haven't finished reading it yet but it does seem to contain primary data about how writing tests has benefited Google products. I would agree with you that the cost of automated testing must be taken into account, not just in terms of development time but complexity and debugging time as well. I find it's still not widely understood that automation adds complexity to a task rather than reducing it. "Ironies of Automation" is a good paper on that phenomenon.

By: Shawn H Corey

Shawn H Corey — Wed, 20 Jun 2012 13:32:00 +0000

#20 has been fixed since before the Y2K problem even came up.

By: Michael Smith

Michael Smith — Wed, 20 Jun 2012 08:07:00 +0000

Well okay but which GPS time do you use? UTC has occasional leap seconds which play hell with some types of real time software.

By: Ultan

Ultan — Wed, 20 Jun 2012 02:07:00 +0000

Some people enjoy getting into all the pathological corner cases, going well beyond the Julian/Gregorian switch but also the subtle differences between the various sorts of astronomical time, dynamical time, TAI vs. UTC vs. GMT etc. One of those people is Alan Eliasen. His physically-typed JVM language Frink does all that and works with several dozen different units of time, as well as several hundred other sorts of physical units as well. It also has some other features like rational arithmetic and interval arithmetic which might be of interest to QA and other people interested in strict correctness.

By: Ultan

Ultan — Wed, 20 Jun 2012 01:05:00 +0000

Or small values of 5.

By: MarlboroTestMonkey7

MarlboroTestMonkey7 — Wed, 20 Jun 2012 00:35:00 +0000

NTP Drift file fun

By: hugh crawford

hugh crawford — Tue, 19 Jun 2012 23:49:00 +0000

I remember setting up a test case where users in Mecca, and somewhere in Australia, were getting long term tech support from a call center somewhere in Indiana. The goal was to figure out the time and duration of the incident as a whole and the
time and duration if the phone call.

About that time I got called for jury duty and I got asked what my job was. I said that I was leading a group of engineers trying to figure out what time it was, so the lawyer asked me to explain why that was such a big deal. I was out of that jury pool in a very short but indeterminate time after that.

By: dolo54

dolo54 — Tue, 19 Jun 2012 23:28:00 +0000

Perhaps you should write a book, I’d read it. Yes I’m referring to the writing of automated unit tests for new functionality. That is, writing a test for every method before you write the method, which is encouraged by many proponents of Agile development, and is referred to as TDD or Test Driven Development.

Our department head recently asked me if I thought we should implement unit testing for all our applications, many of which are small web apps that take 80 man hours or less of dev time. Currently we factor about 8 developer hours to 40 for QA and bug fixing. So if a project takes 40 hours to develop, we assume it may take another 8 hours of developer time to resolve any issues discovered in QA. We usually come in under that estimate. My response was well if we have to write a test for every new method in a class, test the test to make sure it fails reliably, then write the code to pass it, we will seemingly double our development time. So an app that would take 40 + 8 hours to get out the door would now take 40 + 40 + probably another 4 hours, since a lot of ‘bugs’ we get from QA are feature requests missed in the functionality specs. So no it makes no sense at all.

I could see TDD being more useful in a huge sprawling application with many developers and a constantly changing set of requirements, just to make sure people don’t break each other’s work, but I’m not sold that it makes sense for situations outside of that scenario.

Of course manual testing is quite important and I encourage all the devs I work with to test their own work as they are coding. This takes a bit of time as well, but nothing like it would take to write tests for everything.

By: Labbit

Labbit — Tue, 19 Jun 2012 23:13:00 +0000

Alley Cat at 10MHz:

“Holy crap this is fast! Quick, back to 4.77!”

By: corydodt

corydodt — Tue, 19 Jun 2012 22:12:00 +0000

Most of the people I talk to about TDD (myself included) do not even attempt to thoroughly cover code before writing an implementation.

I write a few tests to call APIs, just to remind myself what I’m shooting for and what shape an API client will be when I’m done.

Then implement, then go back and thoroughly cover.

By: Keith Tyler

Keith Tyler — Tue, 19 Jun 2012 22:09:00 +0000

Properly done, a QA group writes tests in advance anyway. The question is whether those tests are written ahead of development or concurrently/subsequently.

But also, properly done, business requirements and functional specifications precede either of those things. The tests then follow (or envelop) the letter of the functional specification.

More often that not, such flaws as you mention are in the functional spec rather than the test cases, which were faithfully descending from the functional spec. Which is why QA involvement in functional spec review is imperative.

Of course, all this requires that you actually develop functional specs in advance of development. Which sadly seems to be becoming less and less common.

Now if you’re talking about *automated* tests, then those could of course have bugs. But you would find that out upon investigation of the automated failure with a manual duplication. If people are using automated tests to verify new functionality, that’s a mistake, for the exact reason you point out. New functionality should always be verified by manual test; then the automation test is developed, and verified by running against the environment in which the manual test passed.

Besides, new functionality is commonly a moving target, especially in the rapid development paradigm. Trying to develop automated tests on new functionality is a prime cause of disillusionment in automated testing. The work required to continually redevelop the automated test to fit the ever-changing requirements is a losing battle; the ROI is almost always negative. Automation is best used for regression (including previously fixed bugs as well as pre-existing functionality). An additional benefit of this is that your automation development is not affected by release-date panic — meaning less likelihood of errors.

(I could probably write a book on this. I probably should.)

By: Keith Tyler

Keith Tyler — Tue, 19 Jun 2012 21:57:00 +0000

As a 10-year QA veteran, it has always floored me just how naive programmers are on the issue of time, and especially time zones. It usually takes a painful amount of head-hammering with a litany of non-conforming examples for them to realize just how much of a mess it all really is, and that their feeble and self-satisfying attempts at compartmentalizing it into something algorithmically simple are utter folly.

They should consider themselves lucky they don’t have to deal with the Gregorian Reform.

By: flosofl

flosofl — Tue, 19 Jun 2012 21:39:00 +0000

But now my brain is all asplody!

Darn invictus for making me revisit my initial assumption and realizing I was WRONG!

DARN YOU TO HECK!

So Paul, you can stop sitting there silently wondering if I’m an idiot.

I am.

By: dolo54

dolo54 — Tue, 19 Jun 2012 21:38:00 +0000

This highlights what has been bugging me about test driven development. Instead of spending time from the middle to end of a development cycle debugging you spend time up front writing tests, which should eliminate most of your debugging time towards the end. But then your tests may have bugs, so now you have spent all this time up front writing tests, then still spend time at the end debugging those tests. I’m not entirely convinced this is an improvement. I would like to see some raw data from software companies that have implemented TDD. How much time have they really saved I wonder. Possibly they are spending even more time writing tests than they would have done just debugging untested code.

By: beemoh

beemoh — Tue, 19 Jun 2012 20:18:00 +0000

If only that photo was taken one minute earlier.

By: invictus

invictus — Tue, 19 Jun 2012 20:02:00 +0000

One of you two certainly is missing the point, yes.

By: Nathan Hornby

Nathan Hornby — Tue, 19 Jun 2012 19:57:00 +0000

Back in the days of the ‘turbo’ button.

By: George Herbert

George Herbert — Tue, 19 Jun 2012 19:28:00 +0000

You can avoid a lot of the inconsistency and insanity if your admins practice good safe timekeeping (use NTP, don’t set up too many NTP servers, etc). But even that can drift, even atomic clocks and GPS time do strange things at times, code has bugs, etc.

But that does not deal with the insanity in timezone offset shifts, virtual server stuff, all the corner cases. This is a good list to print out and read a lot and hang on your wall, to remind you. As someone upthread said, can’t let it paralyze you, but at least you have a fighting chance if you keep a reminder.

By: knappa

knappa — Tue, 19 Jun 2012 19:26:00 +0000

I’m fairly sure he was simply adding to the list.

By: Scurra

Scurra — Tue, 19 Jun 2012 19:26:00 +0000

But it’ll work out OK, as long as you don’t blink.

By: Daniel Earwicker

Daniel Earwicker — Tue, 19 Jun 2012 19:23:00 +0000

“Time passes at the same speed on top of a mountain and at the bottom of a valley.”
Depends whether you can have more fun on top of a mountain or at the bottom of a valley.

By: Daniel Earwicker

Daniel Earwicker — Tue, 19 Jun 2012 19:21:00 +0000

“A time stamp of sufficient precision can safely be considered unique.” Heard about some code today that used a timestamp as a unique ID. When the coder realised that there might be several calls made within a single tick of the timer, he decided to solve the problem by making the code go to sleep for a while until the time was unique again…

By: flosofl

flosofl — Tue, 19 Jun 2012 19:06:00 +0000

I think you’re more or less missing the point.

One hour is as long as the next in all time systems.

Yep. Missed the point.

By: Todd Knarr

Todd Knarr — Tue, 19 Jun 2012 19:06:00 +0000

NTP. Network Time Protocol. Win7 has it built in, and for versions like XP and earlier you can get software like Tardis2000. Find a couple of Stratum 2 hosts near you and sync a couple of your machines to them, then sync the rest of your network to those. I’ve been doing it for 15 years, it can’t be _that_ hard.

By: Paul

Paul — Tue, 19 Jun 2012 18:33:00 +0000

Leap years occur every 4 years.
From the state/province you can determine the time zone.
From the city/town you can determine the time zone.
Time passes at the same speed on top of a mountain and at the bottom of a valley.
One hour is as long as the next in all time systems.
You can calculate when leap seconds will be added.

By: cleek

cleek — Tue, 19 Jun 2012 17:45:00 +0000

oh those stupid programmers.

By: Dick Selwood

Dick Selwood — Tue, 19 Jun 2012 17:42:00 +0000

That assumes that GPS is present. A recent study suggested that there are both natural events, like solar activity, and man made events, like GPS jamming, that could kill the satallite signal.