What drives your development?

In the software testing world, we have an idea of testing strategy. Two common strategies are a risk-based strategy (find all the bugs you can, or, alternatively "find the worst bugs") and a information-based strategy (report about the status of the software). You can even download a course that talks about it.

Your strategy is the goal; it drives how you do things. Strategy helps you decide what to do, and what not to do.

So what are the strategies for software development? Most of the time, most companies have a everything should be perfect or crystal ball strategy. That means that the goal is to make reality conform with a plan that was written early into the project, based on silly-wild-assumptive-guess (SWAG) that someone made at the very beginning of the project. Sometime the SWAG is really just wishful thinking.

Here are a few of the more common software strategies:

Feature-Complete Driven Development: “The Software will be done when it’s done.” Id Software is famous for using this strategy successfully for doom, quake, and other games. Microsoft is famous for failing using this strategy for windows Vista. Tread lightly.

Schedule-Driven Development: Also known as crystal-ball driven development. Under schedule-driven development, the team has to meet some date, and, when things change, the project manager has to manipulate reality to make the schedule work. This strategy generally involves wishful thinking, lots of overtime, and a team that gets what it deserves. Unless, of course, the schedule is padded to the nth degree up front. Then the team might do okay, but the company generally does poorly in the marketplace.

Date-Driven Development: This comes in two flavors. The less-disciplined version declares a date, provides a high-level vision, and thrashes and constantly insists that the date be met. Sometimes this works; sometimes the date comes, the code is an awful mess on the floor, and the project team is burnt out and exhausted. The more disciplined version is called Feature-Driven Development, and I have outlined it below.

Feature Driven Development: Also known as evolutionary development. Using this strategy, the requirements are broken into features, and each feature is implemented as a thin slice, end-to-end, before moving on to the next slice. This strategy enables the team to build a simple working system quickly, and thus hit any specific date. This, FDD trades off time for features. Generally, features are listed and implemented in priority order, so that if the project is late, it can still ship – with less features.

Audit-Driven Development: In this case, the important thing is that your project comply to some external standard. For example, all code must have traceability to requirements, or all code must be reviewed. Generally, audit-driven development requires artifacts which can be inspected to prove the code did what it was supposed to do. Sarbanes-Oxley, HIPPA, and SAS70 are three common auditing standards.

Governance-Driven Development: In this meta-strategy, the person paying for the work gets to decide what drives development, and can change her mind. Under governance-driven development, when a bug is found, the developer doesn’t fix it, because that would mean that the developer has to stop the current work. Instead, the developer defers the question to the appropriate decision maker to determine which they want more – the new feature or to see the old feature fixed. Sometimes strategy and mission statements can automate that decision, but they are written and signed by the person paying for the work.

Technology-Driven Development: When the development house (and sometimes the marketers) run the store, the important thing is that the software use interesting technology, such as XML, Tagging, RPC, SOAP, RSS, object-oriented databases, Ruby, and so on. Dates and features become less important than doing fun stuff. Technology-Driven companies often build robust, scalable, extensible infrastructure before they begin working on features, as the infrastructure will accelerate development. It generally doesn’t accelerate development much, but the coders do get to have a lot of fun.

Phase-Driven Development: Also known as Assembly-Line Driven Development, this strategy views development as a series of steps to be followed in an orderly process. Under phase-driven development, the requirements are specified completely. Then the entire project is estimated and scheduled. Then the software is designed, then coded, then tested, then deployed. Each activity is referred to as a phase; if the project is late, then testing is cut. This means that phase-driven development trades off time for quality.

The nine strategies above just scratch the surface of the motivations a team might have. They are important, because (A) Strategies can be an extension of personality, (B) If you don’t pick your strategy, someone else will for you, and (C) it is entirely possible to do what you believe is right but miss out on someone else’s hidden-agenda software strategy.

Figure out your team’s strategy, then make it explicit and work toward it. Put it on the wall on a big poster. Then, when someone says “You shipped on Oct 1^st without the inverted sort square root feature”, you can point to the poster on the wall and explain that decision.

Developing a strategy, refining and communicating that strategy is an important step in team sports. In software development, unlike professional sports, it is possible for everyone to win.

So let's take the game seriously and develop a strategy.