I was looking at a Home Depot coupon for those low-power fluorescent bulbs when I noticed the instructions to the cashier for how to ring the coupon. There are--I provide proof below--fourteen steps.

This has got to be more complicated than having the air traffic tower talk you through an emergency landing after the flight crew have been incapacitated.

This won't be news to most people who work with ASP.NET, but after a few days of frustration I had to write about it.

ASP.NET is fundamentally flawed. The flaw is in using form POST to do all of the work. Take, for example, the GridView control.

1. Create new web project, open the Default.aspx page designer.
2. Add a SqlDataSource that will return more than twenty records and a few sortable columns.
3. Add a GridView and set its DataSource to the SqlDataSource. Enable Paging and Sorting.
4. Run the page.
5. Sort on a column
6. Choose a different page of data.
7. Click the browser's Back button.

You'll receive a warning message about resending POST data. This shouldn't happen. I've done nothing to update data on the server. All I've done is request data.

Here's another example. What if I create a page with a Search text box and a Find button? Upon clicking Find, I'll display results on the same page so the user can search again. If I do as Microsoft intends, I'll add code to the button's Click event and update something like a repeater control. And then, if I browser Back, I get the warning message again.

In both of the above cases, a GET request should be used. POST is used when the user's request is to change data. For instance, when submitting registration information.

But ASP.NET by design puts all actions into a single form POST. It uses forms to store all state data. You can construct code that performs GET, but that isn't how things work by design.

Microsoft adds an attribute called "runat" to any control, whether its own or the standard html tags.
<asp:Textbox Id="txtName" runat="server"><input type="text" id="txtName" runat="server">

When runat = "server", three things become true. First, from a programmer's point of view, the control essentially becomes a variable that you manipulate from code. The variable's value (such as a text box's text), is eventually sent to the browser as the response.

Second, on the server, ASP.NET will rename the id property of every control, for use in the view state. This means you cannot use css or javascript in the standard way.

Third, the control's contents are stored in a hashed form in a page <input> variable. This means that the form's entire state is stored in the page. Why not? Why not store state on the page so it can be returned each time?

The reason is that you must choose whether to return that state as part of a GET or POST. A GET will pass the state in the URL as a query string, which has limited allowed length. The advantage is a GET doesn't trigger a warning on browser Back. A POST doesn't have a length limit, but has the warning. Microsoft chose POST.

Microsoft has attempted to make http an event-driven protocol. This is fundamentally not the way the web works. The problems with misusing form POST are indicative of their flawed approach.

Goodness knows there are better sites than mine for learning about Scrum, a software development project management method. But, here's my two cents anyway. In other words, I'll give you some opinions along with the facts.

Scrum is an Agile method, meaning it attempts to apply Agile software development principles according to the Agile Manifesto. Scrum isn't mysterious. None of the Agile methods are mysterious. They're just ways of organizing and monitoring tasks. I'll bring this up again in a later post, but for now I'll just say that I like Scrum's organization quite a bit.

Any project has a desired end result, and a set of things to do to reach the result in a given amount of time. Scrum's efficacy comes from not fixing all the tasks up front. Instead, most of the things to do are changeable, except what's being worked on right now. Here are what I consider the basic Scrum terms.

Uncommited Backlog
The prioritized list of items to be completed in the future. Higher priority are at the top. These are usually larger features, not small tasks. They are estimated using Effort Units, which can be anything. The point of effort units is to show roughly how much relative effort an item will take. I'm using Ideal Days, which isn't exactly recommended. The Uncommitted Backlog isn't set in stone, but changes as the release product develops.

Sprint
A committed set of backlog items to complete in a fixed period of time. My sprints are two weeks long, but Scrum suggests a month. Backlog items are pulled from the top of the uncommitted list, and only as many as the team thinks they can accomplish in the sprint period. They then break down the items into tasks and give hours estimates to them.

Sprint Burndown
This chart shows how work is progressing on the sprint. It's a view of hours remaining, so you'll see the team "burning down" to zero.

Daily Standup Meeting
If you're in a team who work in the same place, this is an effective daily ritual. A standup meeting takes about fifteen minutes. The team members tell what they accomplished yesterday, what they'll accomplish today, and what's getting in their way. The Scrum Master notes impediments and works to remove them. This isn't a gripe session. There isn't time for that.

If you're a solo developer, like me, or if your team isn't in one location, you should still do some kind of daily meeting. In a project I'm working on, I try to email the other team member each morning about what I'm going to work on that day.

Tools
Many people use paper and/or spreadsheets to track sprints and backlogs. I've been using a free tool that is adequate for a single client/company, and is designed specifically for Scrum.
ScrumWorks Basic

I can't afford the professional product ($250/user, yikes!), but this tool is helping me on a couple of projects. I may end up writing something of my own that won't, unfortunately, be as fancy, but will better meet my needs.

Links
Here are Scrum links that I found useful. Especially helpful was the discussion of using non-duration Effort Units for uncommitted backlog items. My only grief with this approach is that it isn't management friendly. This is one reason I chose Ideal Days, so I don't have to translate something like story points or t-shirt sizes into an actual deadline. The people who sign my checks want to know "when is it going to be finished", not "how many dragon eggs are left."

Scrum Glossary
Planning vs. Committment Interesting, though I don't totally agree.
Feature Estimation Very helpful.