Coding for the Future

I posted a note on Twitter about some code. In this case, it was the start of a for loop, but with two things in it that I didn’t like. The code is shown here:

for ($i = 2011; $i <= 2021; $i++) {

Both the starting point and the ending condition were problematic for me. This code is used in a scheduling application, to populate a dropdown that I used regularly. It’s always worked, since about 2017 or 2018, and I had no reason to even think about the algorithm. I assumed the code was something like this:

for ($i = 2011; $i <= year(); $i++) {

In fact, when I had issues on 27 Dec, I assumed that things were coded to the current year and I’d be able to schedule things on Sunday night when I got home. Instead, things still didn’t work the first few days of 2022 and I had to get someone to come in from holiday to fix the code. Now it looks back a few years (likely unnecessary) and looks forward one year, as it should.

I don’t know why a developer would bother coding anything like this. Get the need to perhaps test something expediently and limit choices, but hard-coding most anything is a poor idea. There ought to be some logic in how or why you choose values, and that logic often can be expressed in code that adapts to situations. I certainly could have lived with only the current year being available, though that still doesn’t think through the problem space well.

I’ve seen lots of simple bugs in code over the years that are similar to this one. These often occur because the developers haven’t thought through how code might need to adapt to slightly changing situations. Something like a change in the year, or maybe the addition of a time slot for scheduling or a new location added, even a new tax rate. Often I find developers think they have considered the problem given to them, but a little too tightly. They haven’t thought about how their code might change if the user requesting the feature has made a mistake.

Writing code that solves a problem and allows for adaptation to likely scenarios is a bit of an art. It can be hard to do, but great developers assume users will need some changes and plan for this in their solution. They also assume users make mistakes in their specifications and they don’t hard code anything.

Steve Jones


Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged . Bookmark the permalink.

4 Responses to Coding for the Future

  1. JeffModen says:

    Heh… you’ve just experienced what I’ve been talking about all these years and you’ve pushed back on me a bit about. Think about it. 😉 “Good enough usually isn’t”.


  2. way0utwest says:

    Not completely. Often good enough is, but you ought to be thinking about where you will need to flex or grow. I wouldn’t add unnecessary features or optimize everything to the nth degree early on, but I’d be thinking about where I might need to, and spend time there. I’d also be prepared to change/fix things that might be used more than I expected.

    This isn’t the same thing. This is not thinking through an algorithm that will always have a need to look forward.


  3. Greg Moore says:

    This is a common anti-pattern I’ve seen and I’ve never understood why. I mean I get the developer may not want to have a dropdown with an infinite number of future years, but as you say, there’s an easy solution to this that basically works “no matter what”.


  4. jxhyao says:

    Coding is indeed more of an art than an engineering work. Good code is like poem, short in size, rich in meaning. With this said, if a person has read enough good codes (or poems), s/he will be unconsciously write the similar codes (or poems). 🙂


Comments are closed.