The calendar headache and sullied applications
Most applications start off simple. And as they grow, morph and change direction, complexities come along that satisfy the user requirements, while compromising the purity of the application.
The purity of Excel has been compromised by the introduction of Pivot Tables, for example (pivot!).
I often struggle to comprehend the enormity of calendar applications; and get frustrated at how they don’t necessarily behave as expected in certain quirky scenarios. And this is a symptom of that very problem.
Basic calendar management is easy. The business requirements are simple to define (ability to schedule stuff and invite people), and they can be developed without any compromise. But then you strap on some other requirements—calendar delegation, ability for invitees to invite others, management of re-scheduled entries—and suddenly the requirements are not obvious, and their implementation Is likely to impact on the original functionality.
Who is allowed to edit a meeting request? Who gets notified if a meeting is changed? (How) do invitees get notified of additional or removed invitees?
Calendars seem to me the most complex applications that we use on a day-to-day basis. They have so many branches that sully the core, but that are necessary to the richness and usefulness of the application.
I often imagine the various teams at Microsoft, the Oulook team neurotic and literally pulling their hair out at the compromises they need to make; and the Excel team, walking with their heads held high at the relative purity of their application, with the exception of the Pivot Tables and Styles sub-teams, sat embarrassed in the corner at having marginally sullied purity (along with the guy who made 29 February, 1900 into a recognisable day).