High-Tech Humanities

A beta of Google Chrome arrived, and, I installed it post-haste. Much to my satisfaction, it did fairly well. I made sure the whitefrost.com page loaded and operated as expected, and verified the Engine for Web Applications framework and Core Web project (a consumer of Account Manager 4) functioned. Second, I ran through the Engine demonstrations to test key features. The XSLT demos (#4 and #6) caused a little trouble, but, they're currently inoperable for FireFox as well.

So far, I like the interface and I think the browser behaves well. Of course the script engine is amazing. But, I do wonder - why now?

In a somewhat related subject, Cross Site Request Forgeries. I had built in a ward against CSRF as a rotating non-cookie/non-header based token in Account Manager 2 (2002) and Account Manager 3 (2005). Many actions could require a token, and, upon use, expire it and generate a new set as part of the response. In Account Manager 4, this was simplified to more directly deal with CSRF type attacks. Within the data layer, tokens are spooled against the session. In the Core Web layer, a control or a page inheriting from the provided CorePage class, allows a developer to require a ticket, where a ticket describes a token for a specific session and, optionally, a specific page.

Every once in a while, in regards to Engine and Account Manager, I ask myself: Why? If I can't answer that, I'm wasting my time. With Engine, I usually make changes to address feedback (eg: content type problems with libXmlRequest, the AJAX module for Engine), or incremental refinements to the Application Component module. With Account Manager, the driving force changes regularly. Last year, it was mooragefinder.com (currently broken). This year, it was a variety of small projects, such as dalliances with the IMNMotion Behavior Monitor, a customer interaction monitor, and a performance monitor, as well as playing around with bulk data manipulation. At some point, I'll happen upon an idea that seems pretty neat, and start mucking around with it, only to fail in my sanity check hours or days later. That is how the CSRF fix was made: I was mucking around with distributed web application modules, but, couldn't think of what was being offered that people couldn't get elsewhere. So, I fixed a number of small issues to the frameworks, and left the DWAC part alone (though, you can see remnants in the Account Manager 4 download).

If I made more time for dallying with software, I'd spend some time mucking around with Silverlight, and go back to SVG again. I enjoyed SVG with Batik, and my time spent with Canvas. But there is only so much time in the day, and I do want to finish editing my novel.

I've also created a proof of concept with Account Manager 4 and Authorize.Net Customer Information Manager for managing profiles and transactions for registered accounts and/or via some other qualifying identifier. In short, this simply means sensitive information is saved to a secure location, and is coordinated with Account Manager accounts without exposing said sensitive information.

So, Google Chrome (beta) is out, and all seems well in the non-political world. Now, off to hunt problems in need of my solutions.

I've taken notice of an interesting separation in Agile (Scrum, specifically) companies: there are many metrics to track the performance of individual contributors (pigs), and virtually no metrics to track the performance of the stakeholders and managers (chickens). When tracking performance by velocity, contributor performance may be affected adversely by stakeholder and manager influence as it applies to the contributors. Simultaneously, no metric exists to track the effectiveness of the outside influence. As the chicken and pig joke of Scrum goes, pigs are committed, chickens are only involved.

I have experienced firsthand benefits from Agile and Scrum. I believe in many tenets of Lean Manufacturing, Six Sigma, and the Theory of Constraints, particularly how they may be applied through Agile, Scrum, and TDD (although I've not seen as much of TOC's influence). The transition to Agile can be exciting and upsetting. Once everyone falls into the routine and works out the kinks in their particular implementation, the team may hum merrily along. In order to make the most of Agile, team performance should be measured and continually improved. Velocity, for example, is the task-completion over time against the original estimate. Teams may improve their estimations to achieve consistent velocity per Sprint.

Agile has many criticisms. However, most of the criticisms describe implementation or circumstantial problems. These issues, and myriad esoteric gripes, could be applied to any development process. My principle criticism of Agile (Scrum, specifically) is: it can be elitist. Obama and Clinton aside, I think Scrum Elitism is a symptom of lack of accountability, too much management overhead, and too much poor communication.

The symptom of my criticism is easy to explain, and, likewise, easy to correct. Scrum stakeholders are not committed and, while they may be accountable for the end result, they are not always accountable for their involvement as it relates to the contributors. Individual contributors may be measured against factors for which they have no control - that is an unpleasant fact of life. Many Agile proponents promote the concept of individual empowerment within the teams, while simultaneously (if not hypocritically) drawing clear separation between committed and involved individuals. This results in a clear separation of power, authority, and responsibility: the committed convey instructions to the involved, and the involved execute the plan and are responsible for the results. Most Agile materials I've read, and Agile processes I've seen in action, gloss over the responsibilities and accountability of the committed individuals as they pertain to interaction with involved individuals.

My suggested correction is an adaption of the velocity metric to be applied directly to committed individuals: Meeting Velocity. The metric is simple to collect: Every meeting involving one or more committed individuals must be tracked, including ad-hoc office visits to discuss specifications, Scrum, planning meetings, manager one-on-ones, team meetings, et cetera. Scrum teams identify the average lengths of all meetings per ideal sprint velocity, and allocate blocks of meetings points to committed individuals. Each meeting consumes meetings points, and is further rated based on whether it started and concluded on time, was ad-hoc or hastily organized, whether the presenter was prepared, and whether anything was resolved or action items created.

Prior to the start of a sprint, the team can communicate the available number of meeting points to committed individuals. During the sprint, the Scrum team can advise committed individuals when they are exceeding their meeting velocity. Post sprint, the Scrum team can provide a charted meeting velocity and identify whether or not a committed individual was helping or hindering the team.

A beta of Account Manager 4 is now available. Account Manager 4 and Core Web 4 are the projects used to operate this Web site, including the Blog, Forum, etc. The interactive UI elements are managed in Core Web with Engine for Web Applications.

I am pleased with how it has turned out from Account Manager 3.5. Version 4 is much more robust, easier to setup and use, and is a lot easier to develop against.

This is a beta, and some features, specifically, the permissions structure, are still being worked on.