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.