Sunday, December 27, 2009

It’s All About Accelerating In A Curve

Some years ago I met an interesting person who had been a fighter pilot in the Korean War.  At that time, the jets (their first regular use by U.S. combat troops) didn’t have radar to see behind them: they had rear-view mirrors, like a car.  As he put it to me, “I don’t know anyone, including me, who didn’t have brownout underwear when they saw a MiG in the rear-view mirror.”

At moments like that, it’s important to be able to turn quickly while continuing to accelerate.  That’s the message that John Boyd, a fighter pilot extraordinaire, took away from jet fighter dog-fights, and turned into a strategic theory that was the basis for the second Iraq War: whatever one thinks of many aspects of that war, the initial invasion was an astounding success in terms of lives not lost on both sides.  For a more about Boyd and his theories, check out Robert Coram’s book.

Someone’s On Your Tail

And that someone is your competition.  If you can’t accelerate in a curve, you can kiss your product good-bye.  So let’s see what allows a software development company with a product (an ISV: Independent Software Vendor in the industry parlance) to accelerate in a curve, and conversely, what gets in the way.

The blocks to quickly changing direction in writing software are technical and organizational.  We’ll look at each of these.  But first, let’s identify what technical and organizational challenges have in common.

It’s All About Managing Complexity

If the software you are writing were not complex,  you wouldn’t need a team to develop it, and so this discussion would be pointless.  So we are starting with a given: the software is complex, at the level of the domain (the field of business, however defined, for which the software is some sort of solution), the business rules that govern data, and the User Interface (UI) that allows, and guides, interaction with the data.  How you manage those areas of complexity will determine whether your organization can change directions and get to new places fast enough to stay ahead of the competition.  The two areas where you can most influence the management of complexity are in technology, which can help us manage information in all its various forms, and in organizational design, where people interact with information.

A Good Workman Has The Right Tools

The old saying “a poor workman blames his tools” is, well, old: in software development, you either have tools that support quick and accurate development, or you don’t.  Tools that support quick and accurate development have (at least) the characteristics listed below.

  • Application development and runtime behavior is directed by metadata: the behaviors are in the framework, and get triggered by the metadata specified by the designer.  Contrast this with having to embed calls to methods, or worse yet embedding custom code, whenever 95% of common actions need to occur.
  • The application development tools allow for quick, interactive debugging, including the ability to instantiate objects and execute programs while stopped at a breakpoint.  The principle here is getting instant feedback from experimentation.
  • The application development tools must allow easy development and integration of custom-built wizards and builders that interact with the design objects currently opened in the design environment.  Repeated actions must be automated.
  • Related to the point above, the tools must allow easy programmatic opening of any object in the design environment, and programmatic closing/saving of any changes made. It’s all about automation.
  • The application environment must allow easy control over the build process, through normal language commands, so that a custom build process can be crafted to the individual situation of the r&d team.  It’s all about automation, crafted to your team’s needs and style.

Most development systems do not meet the criteria above.  Visual FoxPro combined with any of the application development frameworks available for VFP does meet those criteria.  And the VFP Developer Studio for .Net will meet these criteria.  Anything embedded in Visual Studio, even VS2010, will not meet these criteria: creating a build in VS is a bear, in spite of the various improvement in packaging.  Until the COM-nature of the design environment changes (the editor is in WPF in VS2010, but that’s not where builders and wizards shine), it’s going to remain a bear.

In addition, tools must be used to facilitate team knowledge and interaction, to wit:

  • Software tools will exist to break work down into projects, issues, check-ins, builds and releases.  Projects have features, and implement features through issues; issues can be implementation or bugs, but in either case have check-ins; builds have issues fixed and features complete; a release is a build.
  • All in-house information pertaining to development must be searchable with a tool at least as good as Google (tm) search.
It’s All About The People, Too

What is described above is a customized system for developing software.  Systems require people, however.  Let’s look at what the various people in the know have to say about the people.  A lot of this comes from Joel Spolsky, who has written extensively on this subject (since it directly affects his bottom line, and he is bright enough to realize this).

  • When a team gets above 10 people (I would argue 7, based on the group dynamics differences that apply between small and large groups), the complexity of communications begins to hamper efficiency.  The “2 pizza team” concept applies here: if it takes more than 2 pizzas to feed the team (a concept used by Amazon, and also reputedly by Apple), the team is too big.
  • Everyone on the team has to be really good (one of those 3% to 5% who get work done).
  • Decision-making comes by reaching agreement, not by fiat: when team members are forced to come together in decisions, not only do that have a stake in the outcome, but differences that would affect team functioning get ironed out in the reaching-agreement process.
  • Software developers have work arrangements conducive to deep concentration and focus.
  • Software developers who are kept on the team are well compensated, because only the productive ones have been retained.
  • Software developers are encouraged to expand their knowledge constantly (e.g., by being given Amazon cards for book purchases, and by having a budget for software purchases).
  • Software developers are provided with workstations that promote development efficiency: big, fast, and with multiple monitors (2 minimum, 3 preferred).

And Then There’s Time

My first “job” in software development was at a company that wanted to convert its product to Windows.  They hired me halftime, but the pay was as much as I had made as a psychologist (not much <s> – the economics of being a therapist is that the more efficient and effective you are, the less money you make), and it came with insurance.  Then it turned out they figured the job shouldn’t take more than 6 months.  Oh well…

Good software takes a long time to become good software: Joel says 10 years. Why does it take this long?  It has to do with articulating the domain, that is, in expressing (through the UI and through the business rules that constrain and affect data) that combination of knowledge of the domain, and knowledge of the users, in a way that best facilitates the interaction of the two.  Nobody can get it right the first time, because by the nature of complexity (read Gregory Bateson on this subject), we have to learn to articulate it through experience.  And doing it in one platform does not at all guaranty that one can do more quickly in another platform: what it does mean is that there is a leg up on getting to know the domain, which means there will be more complexity to program, not less.

That 10-year period of getting to deeply know complexity is something familiar to me from my time in psychology: it took about 10 years from the time of my internship until I felt I had a real handle on what was happening in my therapy sessions.  I did good before that, and I learned more after that 10 years, but the essential mastering of complexity took 10 years.  Software is no different.

Of course the software will be out the door in less than 10 years: 1 to 2 years, depending on the starting point, is reasonable.  Plumbing the depths of the domain and translating that into what fits the various user types takes time, however, and that’s where the 10 years applies.

And if your organization can not accelerate in a curve, it won’t be there to make that happen.

No comments: