Sunday, April 22, 2012

Replace Your Unique Web Addresses One-by-One, Just Like They Replace Unique Mailing Addresses in the Construction Industry

Many people in the software industry like to make an analogy between "building a house" and building an information system.

Fair enough, at first thought.

But, do you think construction workers ever tell other construction workers: "This is a lot like programming an information system...etc, etc".

Probably not.

Why? Because construction workers know that building a house is very little like programming information systems.

First of all, one is entirely physical and requires vast amounts of three-dimensional space, while the other, physically, is entirely based upon electronic states and fits inside of the space of a thimble. This is just a small example which could go on for pages and pages.

Yet, all is not lost in the construction analogy, especially if you think about rennovating a house, or better yet: a neighborhood or city improvement project, and compare that to the case of reengineering web-based, distributed information systems.

Neighborhoods, cities, and towns all have discrete, individual buildings. Each building has a Unique Mailing Address.

In a web system, each discrete feature, or "page" also has a a Unique Web Address, better known as a URL, or Uniform Resource Locator.

Suppose now a neighborhood is run down and an effort springs up to rebuild it.

What do you normally see happen?

1. A construction team studies the existing neighborhood, and carefully rebuilds an exact clone of it at a distance, but with more modern concrete, flooring, walls, nails, paint, and insulation, and then one day brings a giant bull dozer, knocks down all the houses, and uses giant helicopters to load every replacment house on top of the same old spot *ALL AT THE SAME MOMENT*?

2. One house or building, or a few depending upon how large the team is, gets rebuilt into something a new buyer wants to pay for and move into. Then, the next, and the next.

Of course, we all know it is the second scenario.

The first is simply fanciful and would be assinine. Of course, due to the physical, three-dimensional nature of construction it also is nearly impossible, at least for an entire street or town to be replaced in a single *MOMENT*.

Instead, house by house, surely enough, the Mailing Address that used to belong to a broken, dilapidated home, is replaced by brand new, valuable, livable homes.

It's a beautiful thing, as they say. Doing this, the team can "keep it moving", and by it, I mean cash flow, and I mean community and homeowner value.

Curiously, still today many software engineers and managers have failed to deeply analyze and ake to heart their favorite metaphor.

We see teams laboring under pressure filled "dead lines" to do a "big bang release in a single MOMENT" to replace a legacy system with hundreds of features or pages.

Or, if they have learned their lesson partially, they may run two systems in parallel, and slowly retire the old one while people are brought into the new one. While better, this option suffers from higher costs and lower return on investment as well as low user value.

This situation is beyond lunacy. In the former case, of single-MOMENT big-bang replacement it may even cross lunacy and enters professional irresponsibility and lack of due dilligence. At best, it showcases a sad lack of knowledge about web servers, lack of understanding about HTTP, lack of understanding about risk mitigation, and ultimately a lack of compassion for the customer and end users.

I blame not just engineers, but big contracting companies who perpetuate this situatiom on paying customers and governments who simply take their word for it that they cannot do it any faster, any better, or with more risk mitigation.

In a web system, as in a neighborhood or city, each feature, page, or controller, or script, or image has a Unique Web Address.

Each of these discrete units can, and should, be replaced in a careful, methodical, but ultimately FASTER, and return on investment increasing and risk reduing way.

Replace the parts at the end of your Unique Web Addresses one by one, just like they do in the construction industry when they replace the parts at the end of their Unique Mailing Addresses one by one.

I will be presenting a demo of how to do this with ASP.NET MVC being used to incrementally replace parts of a system built on classic ASP and ASP.NET WebForms on May 1 via http://www.meetup.com/AtlAltDotNet.

Saturday, April 21, 2012

Thank You to the Resource, of Course

I have been building software systems and web systems for more than 17 years now. During that time, I have seen the web evolve, as we all have, from a poorly understood academic novelty with cryptic error messages about "Resource not found" to something that has completely revolutionized information sharing, and because of that, the world.

As developers, we had to progress through those early, foggy days, on through days when web servers we treated like souped up FTP servers, and into today when feeds and simple REST based services built upon, or aspiring toward, Roy Fielding's architectural principles behind the URI. Tim Berners Lee, the web's original inventor, is still a visionary, and his Linked Data initiative has percolated its way, at least conceptually, into all of our pockets as our phones constantly send small requests and consume data results to keep our apps and lives on track (or swerving off the highway).

Here is my tribute, with credit to Dan North who wrote something similar a while ago:

In the beginning there was the Resource
And it was good
But, misunderstood

Of course.

Then came files and extensions
And this brought much knowledge
Mostly to kids in college
Downloading and sharing things best left unmentioned.

Next came that simple search engine that did not require we select miles of criteria
Much more frugal, all it asked for was a phrase and a click
Then our screens filled with results oh-so-quick!
Days later I got email about my long-lost and newly deceased benefactor uncle in Nigeria.

He died again the next week, too.

Soon came flickr and Facebook
And whether we wanted to or not
No matter hot-or-not
Everyone sent us links saying "Come on, take a look!"

Then the dirt was washed away
And as the soap swirled down the drain
Our eyes opened to the vision from Roy's brain
TBL himself announced for TED: Urls, Links, and Data will save the day!

In the present there is the Resource
And we navigate to its Address
Now understood as the key to our Success

Of course.

Wednesday, April 18, 2012

Focus; Or, If You Don't Know Where You are Going, You May Get There Sooner Than You Think

All too often on a software development project, teams can fall into the trap of getting "too many balls" on the court at once.


Imagine a basketball team which decided that in order to score more points, it would put 5 balls into play and have all 5 players attempt to score.

Or, a baseball team which put one left-handed hitter and one right-handed hitter at the plate in hopes that there would be a better chance of getting a hit?

What about a burrito shop which, in attempting to serve more customers, tried to have multiple people operating the shell steamer and multiple people trying to scoop beans, rice, and meat at the the same time?

Why do these examples suck? Because, it's obvious that nobody would ever do these things because of the physical limitations of space and time (and the rules of games).

So, what if you work on a software team which has several developers, but only one Quality Assurance person? What if that person is the gatekeeper through which all developed software must pass for approval and review?

If this is the case you find yourself in, then do whatever you can to make that person's job as easy as possible. Do not build gigantic inventories of features for that person to review "all at once" or "at a future date". Instead, work closely with them to prioritize the delivery of work for their inspection and review, because there will be things you do incorrectly that you must fix, and they must re-test.

In short: the team must Focus, through collaboration, on the delivery of features in a prioritized, logical sequence that aids review and testing.

The team must avoid working on too many things all at the same time which hinder or slow down review and testing.

To visualize this, I recall a previous article I wrote a couple of years ago: Agile Software Construction is Like Neighborhood Construction.

In summary, imagine you have three forms that you want to deliver to your customer for their web site:
  1. Standard Story Form
  2. Emergency Story Form
  3. Travel Story Form
You know that many components of these forms will be, potentially, identical, such a Title, Description, or Category section.

Upon further analysis, you see that the forms break down like this:
  1. Standard Story Form
    1. Title
    2. Description
    3. Category
    4. Location
    5. Save Draft
    6. Delete Draft
    7. Edit Draft
    8. Submit Draft
    9. Send to Expert for Review
    10. Post to Site
    11. View 
  2. Emergency Story Form
    1. Title
    2. Description
    3. Category
    4. Location
    5. Save Draft
    6. Delete Draft
    7. Edit Draft
    8. Submit Draft
    9. Post Immediately to Site
    10. Send to Expert for Review
    11. Post to Site
  3. Travel Story Form
    1. Title
    2. Description
    3. Location
    4. Save Draft
    5. Delete Draft
    6. Edit Draft
    7. Submit Draft
    8. Post to Site
While there a number of ways you could go about developing this, here are two:

All Features in Progress, None Done

In both approaches, our iteration is 3 weeks long. In the horizontal approach, the team focuses on building up collection of requirements for all story form types. This is followed by developing, testing, reviewing, and releasing the forms, all at once.

As we move from left to right on the time axis in weeks, we see that there is no actual working software delivered after 3 weeks, or 6 weeks of effort. In the 7th week, we potentially have finished the Standard Story Form, followed by the other two in subsequent weeks. After 9 weeks, 3 deliverables have been made.


 

Week 1

Week 2

Week 3

Working Software Delivered

Deliverables Remaining

Business Value Accrued

Iteration 1

Standard Story Form Requirements and Design

Emergency Story Form Requirements and Design

Travel Story Form Requirements and Design

0

3

0%

Iteraion 2

Standard Code and Test

Emergency Code and Test

Travel Code and Test

0

3

0%

Iteration 3

Standard Review, Revise, Retest, Release 

Emergency Revise, Retest, Release 

Travel Revise, Retest, Release 

3

0

100%









One Feature in Progress Until Done


In this approach, the situation is very different in terms of both Time-Value-of-Money and Return-on-Investment for our customer, and in terms of reducing risk for ourselves.

As we move from left to right on the time axis again, this time we stay FOCUSED AS A TEAM on the Standard Story Form and going all the way from requirements to release before the end of three weeks. After three weeks, we see positive numbers in the final three columns! Compare that to the double easter eggs above, and you will agree that staying focused as a team with One Feature in Progress Until Done is a much better approach.

 

Week 1

Week 2

Week 3

Working Software Delivered

Deliverables Remaining

Business Value Accrued

Iteration 1

Standard Story Form Requirements and Design

Standard Code and Test 

Standard Review, Revise, Retest, Release 

1

2

33%

Iteration 2

Emergency Story Form Requirements and Design

Emergency Code and Test  

Emergency Review, Revise, Retest, Release 

2

1

66%

Iteration 3

Travel Story Form Requirements and Design

Travel Code and Test 

Travel Revise, Retest, Release 

 3

0

100%








TODO: Complete