To check if a salesman is good, one classic is the “Sell me this pen” test. To check if a software designer is good, I propose the “Design me a calendar app” test.
That was one of the topic we chose for the software engineering lab, and I loved the results.
There are several reasons why it works well as a design exercise:
Everybody can relate − The domain is easily understood and everybody can relate. Who hasn’t used a calendar app?
It’s easy but not so easy − Managing events that occur once and are short is easy. But it gets more interesting as soon as events are recurring (series), span multiple days, are entered in different time zones, or have rooms associated with them. The design becomes more complex not because independent features pile up, but because the complexity of the core model increases.
Time is messy − A lot of complexity in business software comes from the fact that business rules are “arbitrary”. They make sense at the business level because of processes, domain knowledge, etc. but it’s hard to capture some clear “logic” behind them in software. Introducing such a business domain for an exercise is possible, but takes time. On the other hand, every body knows the idiosyncrasies of the Gregorian calendar already. There is little “logic” behind February having only 28 days and occasionally 29. But, yes, it means a month might sometimes overlap exactly 4 weeks and not 5. Deal with it in you UI.
It’s not just the server − This design exercise raises interesting questions not only in the backend, but also the frontend. What’s the right model? How can we display it fast? What’s the expectation of the user when the start time of a meeting is changed: to shorten it or to move it? These questions don’t have to do with the technology stack. They are inherent to the product. For questions like the last one, I recommend reading The Math of Easy-to-Use from Terry Crowley, former head of development for Microsoft Office, including Microsoft Outlook. He knows about calendar apps.
In the The Mythical Man Month, Fred Brooks explains that one of his favorite interview question is “Where is next November?”.
I have long enjoyed asking candidate programmers, “Where is next November?” If the question is too cryptic, then, “Tell me about your mental model of the calendar.” The really good programmers have strong spatial senses; they usually have geometric models of time; and they quite often understand the first question without elaboration.
Mental models of time are cultural. In western societies, time flows from left to right; the past is behind us and the future in front of us. In other societies, it’s the way around. So I wouldn’t quite expect a specific answer to this question. But I would agree with Fred Brooks that a good ability to model time is a predictor of good design skills in general.
If you don’t get much from this exercise, it will at least make you more aware of the problems that exist dealing with time in computer programs and to use libraries properly. This is a valuable programming skill on its own. The system I’m working on (a train dispatching system) doesn’t work correctly during the night of the daylight saving time (DST) change in autumn, since time jumps back if the DST offsets aren’t accounted for. If you’ve designed a calendar app once in your life, you are aware of such pitfalls.
So, please, don’t design todo apps as exercise. Design calendar apps. It develops real design skills and will make real-world software less buggy.
More
- A puzzle: At work, if we book a room in the calendar we need to physically confirm the reservation using a device on the door within 15 min when the meeting starts, or the reservation will be cancelled. You will be surprised to notice though that if you make a reservation spanning multiple days, e.g mo-fr 8h-17h, you will have to confirm only once on Monday morning! The unit of confirmation is the event as a whole. Not exactly right, but not exactly wrong — What would be your solution?
- Falsehood programmers believe about time and More falsehood programmers believer about time
- Timezone curiosities
- https://en.wikipedia.org/wiki/International_Fixed_Calendar
- https://zachholman.com/talk/utc-is-enough-for-everyone-right
- https://www.zainrizvi.io/blog/falsehoods-programmers-believe-about-time-zones/
- https://twitter.com/reallynotabba/status/1362904827844562944
- https://labs.minutelabs.io/what-is-a-day
- https://www.meziantou.net/misconceptions-about-date-and-time.htm
://ewernli 