The year is 2012 and my current customer has a mailbox quota of 100 MB. Let us try this again: 100 MB.
This at a time when even many free-of-charge mail services throw gigabytes at their customers and when hard drives cost next to nothing per MB. This while the developers on the project team receive at least a dozen emails per day, most of these in bloated HTML, and many having attachments (including various image, PDF, and MS-Office files); and while we send several to a dozen emails per day (depending on day and person).
The importance of such format/content issues is great. (Also cf. below.) In the good old days of plain-text emails, 100 MB would have been enormous. Even adding the wasteful HTML of today can bloat a text by many orders, images make things worse yet, and many MS-Word documents go into MBs per document. Note especially that non-techies, including most project and product managers, rarely have a feel for what formats and what actions can cause a document to blow up in size, which implies that such waste is very hard for the recipients to avoid.
Within a year, I have been forced to make three major clean-outs, as well as several minor, and I still had to archive about half my mailbox on one occasion.
Let us play with some numbers to see that these actions have been predictable: Assume that the 100 MB should last exactly one year, approximated by a low-but-convenient 200 working days. We now have 0.5 MB per day. Assume, compatible with the above and for further convenience, a sum of in- and out-going emails of 25 per day. The average size of all emails, attachments included, is now limited to 20 kilobytes—entirely unrealistic in a typical project. (But might work in a project without bloated Microsoft documents and bloated HTML emails and/or in a project with considerably fewer emails per day.) Then there is the issue of high-traffic individuals, e.g. many managers, for whom 25 emails can be a slow day indeed. Call it 100 emails per day, which is far from a world record, and we are down to 5 (!) kilobytes per email.
But let us say that, by a Hanukkah miracle, the 100 MB does last for exactly one year. What about the second year? Is the user supposed to archive or delete everything from year one? (Or, more continually, everything that is dated on or before “a year ago, today”.) If he is, what would the effects be on his work? If not, even if he keeps as little as 20 MB, he will have that much smaller margins for year two, even smaller for year three, etc.
In effect, the employees are predictably hindered in their work without any real benefit in other areas. While it is true that this hindrance is comparatively small for each individual employee, it becomes a major issue when accumulated over of all employees.
Arguments similar to those used here can apply in many other situations, pointing to a more general principle of “Do not unnecessarily restrict your employees.”; however, for now, I will not discuss more general situations. Still, I caution that the word “unnecessarily” would be important in such a discussion: Some restrictions can make great sense or even be crucial. Consider, as extreme examples of too great permissiveness, giving every employee the root password or the right to enter binding contracts on behalf of the employer.
There is also often the possibility of replacing an unsuitable restriction with a more suitable one, e.g., that a too low upper limit on mailboxes is relaxed in combination with more restrictive rules on attachments, HTML emails, number of recipients, and similar. (Also cf. some of the below.)
Looking in a recent pamphlet from a German computer store (Atelco, 07 / 2012), I find several 2 TB hard drives in the range 100–200 Euro; a 3 TB item is available at 170 Euro—and most of these come with a premium for being external USB drives. Now, I admit, this will not reflect the cost in a professional server setting, with backups, redundancy, administration, hardware suitable for heavier duty, whatnot. Let us just call it an even life-time cost of 1000 Euro per TB (which is likely to be a high estimate) or a tenth of a cent (0.1 cent!) per MB. The 100 MB would then cost roughly 10 cents; moving to 1 GB would imply roughly 1 Euro.
Revising in 2023, I also note that the above prices almost certainly included a distorting 19% VAT, as Atelco was a B-to-C business, and that most businesses could have deducted the VAT for an even lower price. However, understandably, I do not still have the pamphlet and cannot verify this with certainty. (Atelco, as many other store-based computer businesses, has since gone under.)
Other potentially distorting factors include the higher probability that a business needs enough space to buy in bulk and can receive a corresponding rebate, that the costs can be used to reduce taxes, and similar. (But note, cf. below, that this was a governmental project and that other rules might have applied, especially regarding taxes.)
I am also uncertain whether “pamphlet” is the ideal word in English, but what matters is the price ranges.
One single Euro—to be compared with the opportunity costs of e.g. cleaning out large attachments, archiving selected folders, whatnot, on even just one single occasion; let alone the potential negative effects on mood and performance by having to perform a clean-up when there is urgent work to do, or being harassed at the wrong time by emails from an Outlook server claiming that the quota is almost used up. (Incidentally, emails that use up yet more of the quota...) This one Euro amounts to roughly two minutes work for even a regular employee; for me, as an external consultant, it covers far less. Then there are issues like more time needed to retrieve old emails, should the need arise, that more than one place might need to be searched, etc.
And: This assuming that every user actually uses almost his entire quota, which is unlikely. In my case, e.g., the full 1 GB would have seen me through the year without issue and without deletion/archiving/whatnot—but with much to spare.
To my vague 2023 recollection, I was ultimately in this project for approximately two years. I cannot guarantee that 1 GB would have been enough for the entire duration, but it seems very plausible—and, if not, a single session of that “deletion/archiving/whatnot” would have sufficed. (And such actions have fewer disadvantages the older the emails, as the likelihood that renewed access is necessary drops over time.)
Certainly, my average use over this timespan would have been well short of 1 GB.
Quotas have a valid place, but they should be well chosen and consider not only the immediate and immediately obvious costs, but also opportunity costs and other costs of a more indirect or less obvious type. (As discussed above. Generally, cost-saving/-limiting measures must always consider opportunity costs, etc., including, as here, worker hours wasted on unproductive tasks that bring no profit—not just the nominal cost saved or avoided.)
Further, better methods than quotas are usually available. For instance, altering the default email settings from HTML to plain-text (which I recommend as a matter of course for other reasons), advising against unnecessary images and Word/PDF files where plain-text would do, and limiting individual attachments to, say, 1 MB would protect very well against overuse, but without creating more than a minor imposition on the users. Indeed, these measures might actually ensure that a very significant portion of the users never exceed even 100 MB, leaving more space for those who actually need it—and potentially make quotas (on the overall mailbox) unnecessary.
Other ways of limiting waste can be found. For instance, in some settings, it can pay to have a team mailbox or news group in addition to the personal mail box. Messages intended for more than one or two team members can then be sent to the team mailbox/news group, reducing the space used considerably. (Not to be confused with a team mailing-list, which would use one address, but still give each member an individual copy.)
Generally, it often pays to look for alternatives, including those that do not immediately present themselves—and to do so with a clear focus on the goal. A particular risk is that a proxy for the goal is taken to be the goal it self. Likewise, that the priorities of a single department is stubbornly implemented by that department, even when they are detrimental in the big picture of the overall organization. (Note the difference between a department simply performing its assigned function, even when that function is disliked by others, and a department e.g. insisting on something detrimental to the overall organisation for its own convenience.)
However, care should be taken to use alternatives that bring benefit and to not forego the advantages that email has. For instance, if A wants feedback from B on a document, there is much less work needed for both when A simply sends the document to B per email than when he stores it on a network drive, sends an email with the location of the document, and B collects the document from the drive. In contrast, if A wants to formally release a version of the document, a version control system or a versioned wiki in combination with an email announcement is the better choice on several counts.
Looking at space used in the above scenario, the network drive might approximately halve the (non-local) space, as we compare two email copies (one for A as sender and one for B as receiver) with one single on the network drive. While this is an improvement, a real difference is only made when there are a greater number of recipients. Indeed, the network drive might actually end up using more space, as A and B might choose to delete the attachment from their respective email accounts in a controlled manner, while network drives require more effort to manage. (For instance, barring additional conventions, A cannot remove the file in the short term without checking in with B, which would increase the work load, while B cannot remove it without checking in with A, as A might have used the same file towards others, In the long term, even the purpose of the file might have been forgotten and it might not be clear whether it should be kept or can be deleted.)
Of course, the network drive comes with other issues, like the potential risk that B makes a malicious (or accidental) change that A cannot later prove came from B. Vice versa, A can make a malicious (or accidental) change to the document once B has collected the original version, and B will not be able to prove that something has changed between the version that he based his work on and the version on the network drive.
There is at least one very important reason, namely to be able to track who said (or did not say) what when. Not only can this be beneficial to avoid misunderstandings, but it can be a necessary measure of self-protection in some offices and/or with some troublesome persons—and there are instances when a legal obligation to preserve emails is present. Since there is usually no way of judging future need in advance, more-or-less all emails should be saved. Sacrificing this option is foolish, considering how little is gained by the sacrifice.
(Note that, contrary to the default setting of some email clients, it is important to save outgoing emails—not just incoming.)
Another strong reason is that emails can make for a semi-decent and low-effort information store: If all the potentially useful information that has ever been received were to be moved into more formal settings (e.g. wikis) in a blanket manner, the effort would outweigh the benefits—in particular, as merely finding the right place to search might be a costly operation. With a full email history, information of low importance or a low risk of future necessity can often be found through a simple full-text search on a certain folder and/or a certain time frame. (While the more important information can be moved to a wiki in more targeted manner.)
Well, if the mail server cannot handle more realistic amounts of data, then it is time to find better software or hardware. Similarly, clients that struggle with just a few hundred MB of data (most of which need not be loaded at most times) should be replaced with more professional tools. The year of writing is 2012—not 2002.
Both are perfectly legitimate. At home, I store almost all emails in local folders in the first place. (But I use Alpine and its strong folder handling mechanisms; tools like Outlook are weak in this area, and administrating a large email traffic onto multiple folders, be they off- or on-line, is far more work.) They are not suitable for every occasion, however. Consider e.g. the extra effort for archiving, that emails not stored in the mailbox are not available from other computers, and that extra back-up measures might be necessary (or even be impossible due to local restrictions). A particular complication is that a change of email client is not always possible or might require considerable conversion of data, due to format incompatibilities.
Then there are issues like quality and accessibility of an archive. For instance, the official archiving mechanism provided for this project (in my vague 2023 recollection, details might be off) stripped the emails of all attachments, likely removed all HTML code, which could have a distorting effect, and then stored them in a compressed form somewhere. This somewhere was accessible, but with nowhere near the comfort of an email client.
The stripping of attachments is understandable, as the point of archiving was to save space, but it severely reduced the usefulness of the archive, as the most important information, especially when sent by product or project management, is often hidden in an attachment.
HTML emails, in turn, are usually a bad thing and avoiding them from the beginning is laudable. However, if an email has already been sent as HTML, there is no guarantee that a later conversion to plain text reflects the original contents sufficiently closely.
Here, it might well have been better to forego the centrality of the official archive by storing older emails locally, on one’s respective working computer. (However, note the above caveats.)
Here there is some risk: There are general observations like that work will expand to fill the allotted time, that more highway capacity does not necessarily lead to less congestion, and that cheaper energy production per unit might actually increase not just energy consumption but even overall energy costs. It could conceivably happen that users just go from banging their heads on one limit to banging their heads on another limit.
However:
Hardware is sufficiently cheap that even a considerable increase of use would be be tolerable and not alter the main thesis of this page.
With a restriction on the size of individual attachments, changes in email habits due to a larger quota are not likely to have a major effect compared to today. (With obvious reservations for future developments that are not related to the change of quota.)
See also the above suggestions for limiting waste.
The only obvious other component that could affect use is the time period over which messages are saved. This time, however, is not likely to be a problem: Consider simply archiving or deleting all mailboxes of employees/consultants/whatnot who leave; while the individual employee who does not leave simply archives or deletes all emails (saved in one or several folders continually during the project) relating to the current project at its end (or some reasonable time thereafter). Now, one way or the other, most emails will cease to burden the mail server within no more than a few years.
In the minority of cases where this does not apply, it is far more conscionable to archive or delete emails once every few years, when a GB-limit is reached, than to do so multiple times in a single year, when 100 MB is reached. (With regard to both time wasted and the average age of the emails not kept.)
Beware that any recommendation on what could be a reasonable size for a mailbox might need adjustment after even a few years—radically so if larger time intervals are considered: In 1992, a mailbox of 100 MB would have been ridiculously large; while single attachments of 100 MB might be unremarkable at some point in the future. (Or email might have been replaced by some other mechanism entirely.)
The above text was originally written in 2012, but published only in 2023 (after some revisions).
A significant point not mentioned above is what happened when I made a formal suggestion to increase the mailbox size: I wrote an email, very clearly specifying that I spoke of a general increase for everyone. My suggestion was turned down with the claim that I had not given the slightest proof that specifically I, as opposed to everyone else, had the need for an individual exemption from the limit... It might come as no surprise that this was a governmental project. (Specifically, a sub-project or sub-sub-project of the larger German “Zensus 2011” and run by IT NRW, which handles IT matters for the Bundesland of North-Rhine/Westphalia.)
Due to the time passed, I cannot say whether this event took place before or after the original writing, nor whether I had intended to mention it (but not yet had the time) or not. (Similarly, there might have been other points that I had intended to include but have long forgotten.) It might even have been that this absurd answer was the trigger that caused me to originally write the text, as a more natural seeming text would have focused on the more general issue of misguided attempts to save while not considering opportunity costs, to which the absurd email policy would merely have served as an extensive example and illustration. A more personal and specific annoyance with the policy and a last straw of such an absurd answer, however, would easily explain the text.
There is much negative that I once could have written about this project, including concerning pointless bureaucracy, low competence levels, and similar, but where the details are too blurred to give a fair assessment today. (Some other, older, texts might also reference events during this project, however.) Two specific points still worthy of mention:
Attempts to block direct communication between developers and domain experts in favor of a slow and formal road over product (project?) managers, even when it was a matter of clarifying domain issues (as opposed to feature issues)—and, no, this was nothing like the helping layer of a Product Owner in Scrum. Fortunately, in light of accumulated experiences, the no-contact policy was eventually discontinued.
(Note the difference between this and e.g. an insistence that decisions of certain types or certain magnitudes must be approved, or outright made, by product management, must be documented in the right places, must respect certain borders for what may and may not change relative earlier decisions, whatnot.)
A stubborn insistence that this-and-that problem, in particular some cases of faulty inputs and faulty data combinations, were prevented by organizational measures (“organisatorische Maßnahmen” or similar) and need not be considered when writing the software. The result was that these organizational measures failed again and again, and that there was no protection against the faulty whatnots in the software. In a next step, needed corrections had to be made through SQL scripts, because there was no corresponding functionality in the administrator’s interface. The time wasted for development alone, let alone other parties, was larger than the cost of implementing proper checks and/or extending the administrator’s interface would have been.
Tip: If there is the technical possibility for a user to do something wrong and if the user base is of a non-trivial size, some users will screw up, quite possibly many users and/or the same users repeatedly. Organizational measures might reduce such screw ups, but are highly unlikely to eliminate them. This while it often matters less whether a particular problem occurs rarely or often and more whether it occurs at all.
Generally, I would caution to think twice before accepting work in governmental projects. During my days as a consultant-in-employment (as opposed to my days as a free lance), my employer landed me in two such projects and they were both train-wrecks. Combine these experiences (which might have resulted through sample issues or be specifically German) with the apparently global low competence of civil servants/public employees, apparently global bureaucracy issues, apparently global whatnot, and pessimism is warranted.
The following is an automatically generated list of other pages linking to this one. These may or may not contain further content relevant to this topic.