False Agility

In my last post, I mentioned that I am working privately on sorta-Scrum tracking system for agile project development. My working name for the project is TMX. (T)eam (M)anagement and the X is because everything cool that ever came out of the Fox world has to end in X.

I'm not going to repeat here the definition of agile processes or Scrum in particular, but if you already understand it you know that there is a high reliance on the professional judgement of the development team and that management acts more as an obstacle remover and facilitator.

What bothers me is that, for Scrum at least, this blind assumption that the development team knows what they are supposed to be coding and most whitepapers confidently posit that you can retrofit any sort of project management structure into Scrum.

Wrong.

Birds cannot fly free without the structure of wings. That is, no amount of expertise or instinctive talent will guarantee success without the support structure. Scrum seemingly substitutes open communications between customer, management, and the development team as a panacea for that structure.

This is wrongheaded. Open communications are great, and absolutely required for agile development, but must be backed up by rigid and detailed functional requirements which are created from dedicated and formal requirements gathering.

Scrum is described as best working for small teams. My take on this statement is that this is the case when all you have is real-time communications and no written, formal documentation of the form and function of the application. This is absolutely required to reduce bad assumptions and people wheelspinning by having to undo the wrong work.

I have found in the real-world that detailed requirements are absolutely a key; they are the wings of the bird. Good strong wings let that bird fly with the greatest agility...

VFP Coding

So I'm working on a new VFP application that tracks team management towards an overall project. It's loosely Scrum based with a lot of school of hard knocks thrown in. If I get it working the way I want to get it working, it really does have the potential to be one of the best agile process project management apps out there.

Aye, there's the rub. Getting it working the way I want.

It's been 5 1/2 years since I wrote a soup-to-nuts VFP application. Yes, I've written monstrous amounts of code during this time but most of it small routines for algorithms or test scenarios. But I haven't put it all together for quite some time.

And it's downright embarrassing what I've forgotten. I feel like Werner Von Braun with Alzheimers asked to design a Mars booster. Sure, I'm an expert in the foundations but the step-by-step part is a bitch.

There is so much experience-rated wisdom in being a good VFP developer that you don't realize until you've been away from it for a while.

Development Costs Inflation Model

There's a theme I've been pounding on for years that, IMHO, developer productivity is actually going down rather than up over the years. I used to make comparisons in developer productivity between command-line interfaces (CLI) and graphical user interfaces (GUI).

My point has been that developers were focused on functionality in the CLI world because of limited presentation options. Therefore, one would spend maybe 10-20% of the project designing the interface and the rest of the time with functionality and reporting.

With the advent of Windows 3, we're GUI and now had a whole bunch more things to plan that had nothing to do with the actual functionality of the application...such as what fonts to use, precision control placement, modal versus non-modal dialogs, etc. So, perhaps, we're looking at 50% interface and 50% functionality.

Now with a lot of business applications exclusively using web interfaces, we have a third area of concern in application development: systems integration: Network issues, request handlers, security, etc. Plus, web UI is not quite as flexible as Windows UI so we spend even more time working out the user interface. I figure that now we spend 30% on integration, 40% on interface, and 30% on functionality.

And, so.....let's do the math but establish a truism first.

GUIs, be they web or desktop, do not generally enhance specific business functionality; they enhance user productivity. For example, being able to look at 5 different chart-of-accounts entries, each in it's own spiffy non-modal window, does nothing to aid the process of closing a period nor does it force multiply the developers time to implement the closing code.

So, the rule here appears to be that GUI applications do not shorten the development time to create business-oriented functions. And, arguably, web applications increase the amount of time required to implement the user interface because of the lesser flexibility of web controls over desktop controls.

My example above is typical of a simple accounting application. Let's look at what the CLI development effort might well be:

UI design and coding: 20% = 20 hours
Functional design and coding: 80% = 80 hours

TOTAL 100 hours

Now let's look at a desktop GUI application. Bear in mind that our UI efforts are 50% of the time now, however, there's nothing in a GUI versus CLI that makes functionality; i.e., closing a fiscal year, any easier. I'm reversing the order of the tasks to highlight this:

Functional design and coding: 80 hours (50%)
UI design and coding: 80 hours (50%)

TOTAL 160 hours

The cost to implement the GUI solution is 60% higher for the developer with little or no increase in business productivity.

With the web app, the numbers go to:

Functional design and coding: 80 hours (30%)
UI design and coding: 96 hours (40%)
Systems integration: 80 hours (30%)

TOTAL 254 hours

The web application is two-and-a-half times more expensive with little of no functional gain. Scary thought, isn't it.