Strong opinions, weakly held

How simple features become complicated

This post is for all of my non-programmer readers who have to deal with programmers on a day to day basis. It’s a description of how things that may seem simple really aren’t. Maybe I’ll write another post later about how things that seem complicated can be very simple to fix.

I’m working on a Web page that is supposed to display some events from a Google calendar. When I started, it grabbed the JSON feed from the calendar and displayed the first two events in it. Generally speaking, these are the next two upcoming events on the calendar. The feed contains a lot more events, though — some from the past and a lot from the future.

Unfortunately displaying the first two events in the feed did not meet the exact requirement, which turned out to be: display the events from the first two upcoming dates on the calendar. If there are multiple events on one of those dates, show them all. If there are not two upcoming dates, show one or two dates from the most recent past (so that two dates are always displayed).

Outwardly, this seems simple. Reorder the calendar in ascending order and pick the right slice of events to show.

The old code just grabbed the first two events in the list and printed them. The new code had to do the following:

  1. Extract the dates from the feed and convert them into JavaScript Date objects.
  2. Sort the events from oldest to most recent.
  3. Split the events into two lists — events in the future and events in the past.
  4. Iterate over the future events, picking out the events from the next two dates, and adding them to a third “events to display” list.
  5. If there are not two dates with events in the future, sort the events from the past in the future in descending order then pick out enough dates to fill out the “events to display” list.
  6. Sort the “events to display list” in ascending order.
  7. Display the final list of events.

Making that list was easy, but figuring out all of the requirements and then coming up with the best way to implement the solution took plenty of time from the point when the designer said “sort the events in ascending rather than descending order” to the time it was deployed. And all this for one little module on a page that contains lots of other information.

This is why I generally forbid the use of the word “just” when people are making feature requests. When it comes to developers, the word I forbid is “should,” but that’s another story.


  1. Great post! Calendars and Date formats in general are always a thorn in one’s side, but I think you briefly explained to none-developers how something seemly so simple (and for only one part of the page) can require so much planning and work.

    I’m looking forward to reading… “Should: The forbidden word”


  2. Doh! That should be “Non” not “None”.

Leave a Reply

Your email address will not be published.


© 2024 rc3.org

Theme by Anders NorenUp ↑