One of the things I enjoy the most about being an industry analyst is that I've spent the past six years meeting some great developers. Personally, I’m not sure I could cover any other technology area then application development. The reason is simple: I see developers as a worldwide force for good (It's almost axiomatic, as the bad apples become "hackers"). Developers innovate, they create, they push technology forward — and they are fun to go have a beer with at the end of the day.

While writing for developers is fun, it’s not always easy. For the past few years, my topic coverage areas have sometimes felt a bit disjointed — almost as if there are two different developer communities out there that I deal with. In the past, I've referred to these groups as the "inside the firewall crowd" and the "outside the firewall crowd." The inquiries I have with the first group are fairly conventional — they segment as .NET or Java development shops, they use app servers and RDBMSes, and they worry about security and governance. Inquiries with the second group are very different — these developers are multilingual, hold very few alliances to vendors, tend to be younger, and embrace open source and open communities as a way to get almost everything done. The first group thinks web services are done with SOAP; the second does them with REST and JSON. The first group thinks MVC, the second thinks "pipes and filters" and eventing. I could go on and on with the comparison.

To pick up the narrative from my last post, we're currently one week into the First Robotics build season for 2012. Team 811 is busy working away on an initial sprint. The goal is to get a minimum viable product (a drivable robot) up by the end of sprint one, which will then be used as a base to move toward a competitive robot that can play this year's game, Rebound Rumble.

So how did Team 811 get from "huh?" to full-speed prototyping in 4 days? How does anyone get 40+ teenagers moving in the same direction when the number of unknowns is significant and the problems to solve look insurmountable? For team 811, the key was starting with a 3-day process called "Collaborative Problem Solving (CPS)." Think of it as a pre-sprint process to build team buy-in and reduce downstream back-biting and second guessing.

So what is CPS? It's a technique that starts with a problem statement and then encourages divergent thinking to brainstorm creative solutions to that problem. Criteria that allow evaluation of those potential solutions are then applied by the entire group. This starts a process of combining divergent ideas into stronger overlapping concepts and identifying those ideas that have the strongest combination of feasibility and ability. The result would be recognizable to many agile teams: a burndown "punch list" of items and strategies to drive early prototyping and the team's first sprint.

Revolutions take two forms. The most familiar kind is the noisy, conspicuous, disjunctive event that marks a clean break from the past. Yesterday, George III was our monarch. Today, he's not. The other kind of revolution is a more gradual and subtle event, when multiple forces pointing in the same direction push people into a new world. The shock of Pearl Harbor, the power vacuum left by a devastated Europe and Japan, a reinvigorated economy, and an aggressive superpower adversary made Americans feel, for the first time, that they needed to be far more deeply involved in international affairs than ever before. Without any formal declaration, Americans became internationalists after 1945.

Something like that second kind of revolution has happened with software requirements. Over the past decade or so, organizations grew increasingly worried about the problems that took root in bad requirements. The problems took many forms (portfolios filled with applications no one was using, users unhappy with the software that complicated their lives more than helped them, ideas that no one vetted carefully, etc.) and arose from just as many sources.

All of these discontents pointed in a common direction: Take requirements more seriously. In Forrester's Q1 2011 Application Development And Delivery Organization Structure Online Survey, "improvements of requirements" appeared at the top of the list of initiatives that would improve software development the most.

Do you ever wonder which IT investments really drive competitiveness or comparative advantage for your firm and which are there simply to support mundane processes that are identical to those of all your competitors? Do you ever wonder if it might make sense to standardize on "best practices" for non-differentiating processes and supporting application implementation?

Received wisdom is that accounting processes are not differentiating and so it makes the most sense to support them with packaged apps or maybe with software-as-a-service solutions. Larger firms often implement shared services for financial management across all their business units or even outsource altogether apparently dull processes such as invoice settlement or collections.

But does that really stand up to scrutiny?

One retailer, with which Forrester worked, confessed to having 17 definitions of margin depending on which types of supplier rebates and volume discounts were included. We asked how they calculate markdown and they grinned.

The more I thought about it, the more this fact disturbed me. In some types of specialty retail, inspired opportunity buying is the key to competing with the bulk buying muscle and supply chain scale economies of global discount retail chains.

Many retailers import merchandise and have to calculate "landed cost" based on customs and freight invoices that arrive long after the goods in question have been sold. What price weighted average actual cost accounting, or margin calculation, in such a scenario?

Where is the scope for creative dealmaking in standardized accounting applications that deliver lowest common denominator functionality across verticals as diverse as local government, with its focus on fund or commitment accounting,  engineer to order manufacturing with a focus on multi-period project costs and retail with a focus on margin measurement and management?