Before the PC revolution began—when computing resources were expensive and shared—developing optimal software systems took months and sometimes years.
That time frame changed when the PC and Microsoft Windows became the default development platform for corporations. Developing software that optimized the available resources was accelerated by development managers who promised that Rapid Application Development (RAD) systems using products like Visual Basic, PowerBuilder and SQL Windows would allow IT departments to roll out applications quickly.
Because we are now on “Internet time” we have to be able to quickly develop and deploy Web sites and Web-based applications that connect to existing back-end systems.
What’s interesting about all of this is that the basics of software development really haven’t changed.
Sure, the tools have changed and the scope has gone from hundreds of users (mainframes) to tens of users (PCs and networks) and now millions of users (the Internet). Despite tremendous expansion and new development tools, successful projects still require a balance of three fundamental variables: features, schedule and resources.
During the mainframe era, most development shops chose to maximize resources. PC developers, given the robust nature of their new development platform, chose to maximize features. The time demands of the Internet age virtually require companies to continually update their platforms and applications to meet the needs of their customers.
During the next three weeks we’ll look at what your development staff needs to focus on to develop Quality Software Quickly, a process Tim Landgrave has termed Q2 Development. Next week, we’ll look at making sure developers produce what customers want. We’ll also outline steps to ensure the process and the products are properly tested.
In order to do this, the schedule has to be the most important variable.
Focusing on the schedule
To undertake a Q2 development initiative you must first agree to make default assumptions for all development projects. All developers should agree to abide by a simple set of rules and requirements to ensure your success:
- All product development timelines consist of three phases: definition, development and delivery. These can be further subdivided to produce a product vision and specifications during the definition phase. The development phase is composed of code development and code completion. The delivery phase includes platform testing and product rollout.
- Complete each phase in sequence. Each phase has specific deliverables that must be complete before moving on to the next phase.
- All product development timelines are fixed at a specific number of weeks or months. For our projects, we use three months—one month each for definition, development and delivery. By their nature, all Q2 products are fully developed by repeating these phases and successively adding or completing the features of the product.
You should never consider a Q2 product to be “done.” You are only releasing a product at a particular level, assuming that additional features will be added when resources allow.
- Managers of Q2 projects will sacrifice features or add resources to make schedules. If the product is de-featured to the point where it’s no longer useful or where the resources required to produce the product become too expensive, then the definition phase needs to be revisited (using checkpoints).
- Each phase includes a mid-phase checkpoint where senior managers make a decision on the fate of the product.
- Definition phase mid point: After developing the product vision, managers make a go vs. no-go decision. It’s much less expensive to kill a project at this point than to spend time and resources developing specifications and applying development resources to a project that lacks vision or direction.
- Development phase mid point: Senior management has to make a feature vs. resource decision. If there are features that have to be implemented but cannot, given the existing resources, then resources have to be added. More often than not, however, the decision will be made to reduce or eliminate features in order to meet fixed resource or scheduling requirements.
- Delivery phase mid point: You are now faced with a resource vs. schedule decision. If all the features haven’t been properly tested, then moving into a product rollout phase is foolish. Now the decision is whether to apply additional testing resources or to extend the testing period with existing resources. The only time you should be willing to sacrifice schedule is to ensure quality by completing the proper testing before deployment finishes.
- Agree on a standard set of tools. To make these aggressive schedules, you have to decide on a standard set of tools and platform software. For example, if you’re a Microsoft shop you may make the following assumptions:
- All systems will be developed using Microsoft Visual Studio as the development toolset.
- The server platform will consist of Microsoft .NET Servers (Windows 2000 Advanced Server, SQL Server 2000, Exchange 2000, Internet Security and Acceleration Server 2000, Application Center 2000, Commerce Server 2000, and BizTalk Server 2000).
- The supported desktop platform will be one or more of the following: Windows 32 applications, HTML 3.2 compatible browsers and Internet Explorer 5.0 and higher. Desktop platform selection depends on the audience and the skill set of the developers assigned to the project.
If you’re a pure UNIX shop, then you’ll have a similar set of core development standards. It’s likely that your development shop will include a mix of development tools and platforms.
- Define the reference platform. In addition to defining the platform and tools for development, you’ll also have to design applications to run on a standard reference platform. The reference platform defines standards for major development areas including security, data access, physical architecture, licensing standards, etc.
You should define, develop, and deliver the reference platform just like any other product. All products should then reference the version of the reference platform on which they’re architected to run.