When asking about the capacity of a program, you also need to consider what happens when you decide to stop using the program


An internal customer had a question about a tool, let's call it Program Q.

As part of our gated checkin system, the system creates a new record in a Program Q table to record details of the checkin. (What tests were run, who did the code review, that sort of thing.) We are considering incorporating the Program Q record number as part of our version number: major.minor.service­pack.hot­fix.record­number. What is the maximum number of records per table supported by Program Q?

Now, the easy way out is to just answer the question: The theoretical maximum number of records per table is 2³²−1. Even if your gated checkin system's throughput is one checkin per second, that gives you over a century of record numbers.

But answering the question misses the big picture: The limiting factor is not the capacity of Program Q. The limiting factor is how long you plan to keep using Program Q! Before the century is up, you probably won't be using Program Q. What is your transition plan?

In this case, it's probably not that complicated. Suppose that at the time Program Q is retired and replaced with Program R, the highest record number is 314159. You could just say that the version number in the binary is the Program R record number plus 400000.

If you're clever, you can time the switch from Program Q to Program R to coincide with a change to the major.minor.service­pack.hot­fix, at which point you can reset the record­number to 1.

Comments (27)
  1. Joshua says:

    Well in our case, Program R doesn't count like that at all (yay distributed source control).

    [Program Q isn't source control. It's a database. Even if you use distributed source control, you might still have a system where everybody must fill out paperwork before submitting a pull request. That paperwork is recorded in program Q. From that paperwork you can determine exactly which set of source code was used to produce that build. And since record numbers are monotonic increasing, you satisfy the version number requirements. -Raymond]
  2. SenneVL says:

    Application lifecycle management should not stop at the deployment stage. It's a common mistake to not calculate the impact of a component going end-of-life.

    I've seen new solution entirely built around deprecated technologies. No wonder upgrading from 2003 seems hard for a lot of companies out there

  3. Anon says:

    "Before the century is up, you probably won't be using Program Q"

    People are still using CP/M.

    People are still using VAXes.

    People are still using 16-bit applications.

    People are still using Visual Basic.

    People are still using webapps that only work in IE5.

  4. steven says:

    @Anon Yes, but the end of the 21st century is a lot farther away than the end of the 20th century was to the creation of the technologies you mention. Also: before the century is up, you probably won't be alive to use Program Q.

  5. Kevin says:

    @Anon:

    >People are still using 16-bit applications.

    The enterprise world doesn't count as "people."

    >People are still using Visual Basic.

    [flamage voluntarily redacted]

    >People are still using webapps that only work in IE5.

    Again, this is basically limited to the enterprise world.

  6. meh says:

    400 large ought to be enough for everyone.

  7. Joshua says:

    @Kevin: Got a replacement for GAX? It does polynomial curve fit.

  8. Scott Brickey says:

    so they're wanting to go from a standard versioning format of 4 numbers, to a non-standard format of 5 numbers?

    I know this is similar to TFS (which by default appends an incrementing number to each build within a day)

    But none the less, let's call the approach "bad design"… instead, blend hotfix and record into the standard "build number", and call it a day.

  9. Ken in NH says:

    @Anon

    People are still riding horses and some even use buggies. That's not a useful argument against building roads with an eye open to future developments in automobile technology. It would be ridiculous to say, "we thought of painting lines with infrared reflective material for autonomous cars to use in the future, but some people in Pennsylvania still drive a horse and buggy, so decided against it."

  10. Guest says:

    @Anon

    "The theoretical maximum number of records per table is 2³²−1. …that gives you over a century of record numbers." "Before the century is up, you probably won't be using Program Q"

    People weren't using CP/M, VAXs, 16bit applications, VB, or webapps that only work in IE5 back in 1915.

  11. Paul Coddington says:

    Um… "Before the century is up, you probably won't be using Program Q" in the context of the article actually means "before the application has been in use for a hundred years".

  12. Benjamin says:

    I just wanted to say, I had pie for lunch so I appreciated the record number chosen in this example.  

  13. Anonymous Coward says:

    @Anon:

    A few days ago I had to write a program that would looks for any unread emails with "!!! AUTO-FORWARD:" on the first line, then forward them (removing the first line and forwarded message header) to the addresses listed on the rest of the first line. In VBA.

  14. rioki says:

    @Scott Brickey

    I don't know about you but, major.minor.servicepack.hotfix.buildnumber it not such an exotic version string. It is normally not user visible but, build numbers make sense. But then again, build numbers are reset when going to the next version.

    Speaking of odd version numbers, I work in a company that uses the version stings as follows:

    major.minor.servicepack.hotfix_devcycle.iteration.build.buildatempt

    Under normal circumstances devcycle=01 and buildatempt=01, but it this scheme incorporates the odd case that you attempt multiple times at developing a version and that build failure are a normal operation mode.

  15. Boris says:

    Wait a minute, could it be that Anon didn't realize Raymond was discussing source control? Even if some people are still using Visual Basic, it's not like VB6 itself is being developed any further, meaning no more record numbers for it.

  16. JW says:

    I'm confused. OurApp creates records in a table used by Program Q. Said records have a number. Now the plan is to have the version-string of OurApp have a recordnumber attached to it? Does OurApp only ever deal with a single record in Program Q for that specific release of the OurApp software? If not, how do we deal with multiple records? How about multiple deployments?

    Somehow, I feel like I am completely misunderstanding. Is the Program Q version number something that applies to the db schema Program Q uses?

  17. Boris says:

    @JW: you develop and check in BlogMaker 1.0.1.1.235 (Version 1.0, Service Pack 1, Hotfix 1).

    Testing finds bugs, you check in 1.0.1.1.236.

    Testing finds more bugs, you check in 1.0.1.1.237.

    Testing passes, you release 1.0.1.1.237.

    In a separate branch, you develop and check in BlogMaker 2.0.0.0.238 (Version 2.0).

    Testing finds errors, you check in 2.0.0.0.239.

    Testing finds errors, you check in 2.0.0.0.240.

    Testing passes, you release 2.0.0.0.240.

  18. Dennis says:

    The other bigger picture could also be totally different. Maybe the Major.Minor.ServicePack.HotFix is part of the file-version. Like in C# we do with:

    [assembly: AssemblyVersion("1.0.0.0")]

    Then you already have a problem much sooner, because the revision-part can't go above 65635. (Yes, found out the 'hard' way).

  19. Brian_EE says:

    "In this case, it's probably not that complicated. Suppose that at the time Program Q is retired and replaced with Program R, the highest record number is 314159. You could just say that the version number in the binary is the Program R record number plus 400000."

    Or, if it's an SQL database, you could create the Program R table so that the record number column starts at 400000 (I would hope a record number field is auto-incementing and unique).

  20. DWalker says:

    "People are still using Visual Basic.".  Yes, Visual Basic .NET 2013 (as created by Visual Studio 2013 and other programs) is still being used, even for new development.  Some people find it easier to read than programs that have curly braces sprinkled around… VB.NET has just about everything that C# has (I ran across lambda expressions a couple of days ago, and they work fine in VB.NET 2013.)

    Or did you mean some older version of Visual Basic?

  21. Bob says:

    @Anon:   On the other hand, computing history is littered with well meaning attempts to replace functioning systems with completely new systems which drained financial resources and which ultimately had to be abandoned.

  22. Anon says:

    @DWalker

    "Visual Basic", as in pre-.NET

    VB.NET is basically a different language. It is still terrible, but it is terrible for reasons that can mostly be ignored.

  23. DWalker says:

    @Anon:  VB.NET has the capabilities of C#, with a different user syntax.  Everyone has preferences; obviously you don't like VB.Net… and that's fine.

  24. Anon says:

    I'm pointing out that developers *EXPECT* their applications not to be in use for decades, or centuries, when in fact, we have entire enterprises planning (and dependent) on using the same software they've been using since the 1970s until the end of time.

    We rarely run into problems where people CAN'T transition to a new application.

    What we run into are problems where people *REFUSE* to transition to a new application, causing disasters like the billions (trillions?) spent refactoring 20/30/+-year old code to avoid Y2K issues. (that same 20/30-year-old code is quickly becoming 40/50-year-old code, that we rely upon for critical infrastructure, that very few people can maintain)

    So the limiting factor for Program Q is, indeed, more likely to be reaching the maximum record number than it will be transitioning to a new application.

    (I would also bet on Dennis there, or that they use this number in some other application which has a different limit that they're going to reach first.)

  25. Engywuck says:

    even the Windows 10 Technical Preview still contains VB6 support (at least msvbvm60.dll is still in %windir%SysWOW64), so Microsoft will probably support this ageing codebase indefinitely. So why change? ;-)

  26. Boris says:

    @Engywuck: supported != competitive

  27. 12BitSlab says:

    One of the most used programs ever and is still executed many millions of times per day was written in the 1960's — IEFBR14.  Code can, and does stay in production for a VERY long time.

    With that said, Raymond is correct in saying that one must plan for long term use of data.  Regardless of whether a particular program/system will meet one's long term needs, very often there are regulatory issues surrounding the retention of records.

Comments are closed.

Skip to main content