Email Quotas Aren't Stupid

http://therubberboy.com/contortionist.php

I recently heard a project manager lamenting their “limited” email. How big is our limit? Well, I assume that for the normal peons in my company it’s about a Compact Disc's worth: 600MB. That’s almost as much as Gmail’s (current) 65GB allotment for their free account, right?!? It’s only 2 orders of magnitude difference, no big deal.

sigh

Clearly, storage isn’t THAT expensive, and it wouldn’t take much effort to make everyone's email have more room to breathe. Considering the cost for storage vs the cost of time and mental capacity for your workforce, it would seem like giving larger email quotas would be a no-brainer.
While this line of reasoning could be fleshed out on its own, I’m not going down that road. Too easy. I’ll go ahead and make the argument AGAINST larger quotas.
Software professionals love to joke that 640K should be enough for everybody, even if the whole thing is apocryphal. Working with systems having finite resources is part of the work that we do. That said, I cannot quite figure out why one’s work email would need to be so large. Could you imagine what the physical equivalent would look like? How many folders and stacks of paper would be needed to keep track of that much data IN EMAIL FORM? I think the larger problem is that you’re using email wrong.

Agile vs. Estimates

Once of the most common issues I hear when it comes to Agile adoption is the "lack of estimates." I'm not sure where this notion comes from precisely. Looking at the manifesto and principles, there doesn't seem to be mention about estimation directly, but I suppose it could be construed from this one line of the manifesto:

Customer Collaboration over Contract Negotiation

The terms contract and negotiation have fairly negative connotations in my mind, but perhaps the business folks are more comfortable with them. After all, the work of software is to perform a service or operation in some way which saves or makes an organization money. Any time the business spends money, this is why. The customer doesn't care about PHP or HTML5 or NoSQL; your system could run on Unicorn blood and Kraken oil so long as it solves their problem. You deliver a product or service which solves a problem and they are paying you to help them solve it. Contracts are the formalization of what it means to solve their problem with the understanding of what it will cost to solve that problem. Negotiation is the process of establishing a contract, so that all parties have a common understanding.

Spell Checker

College Days

In college, the primary instructor for the Data Structures class is known for his frankness with students who need to drop his class. Either they're not prepared (despite having met the prerequisites), have too heavy a course load (the overachievers), or are not cut out for "serious" programming (weed-out). In a typical semester his roster would drop by 50% between the first day of class and the "drop date" (last day to drop a class without impacting your GPA). So, it was without great embarrassment that I dropped his class a few days in (see reason #2) and retried the following semester.

Welcome Changing Requirements

Here's another post about one of the 12 agile principles. Enjoy!

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Does that make anybody else cringe?

This is clearly for our customer's benefit. They're listed explicitly in the second sentence and implicitly in the first. It's a nice goal, but really, what's the deal with changing the requirements so late in the game? How is that supposed to work, really? How do we do that?

Self-Organizing Teams

​The best architectures, requirements, and designs emerge from self-organizing teams.​

This is one of those 12 Principles that raised doubts in my mind when I first read it. Most of the other principles seem patently valid. This one, though, begs a deeper dive. I'll give you my definitions and you're welcome to point out the flaws:

• Architecture - the structure of the underlying components of a system 
• Requirement - the description of functionality of a system 
• Design - the user's experience of a system 
• Self-Organizing Team - the set of people who decide to build a system

There's another word in this principle that give me the willies: Best. What does it mean to have the "best" architecture, the "best" requirement, or the "best" design? How do you know you have such a thing? How can we know that such a thing even exists?