Because of the rapidly changing production and distribution requirements in today’s evolving broadcast infrastructure, some will assert that the traditional engineering process is too slow. With the emergence of new delivery channels, consumption devices and programming formats, deployment projects that take more than a few months will miss their windows of opportunity — first-to-market has value.
Software application designers have faced this challenge and developed methods to address dynamically changing requirements, presented during application development. To the uninitiated observer, these methods may seem haphazard and ad hoc, but there is an underlying design process philosophy.
Agile and extreme programming
Agile programming (AP) and extreme programming (XP) are two software development methods that address the issue of changing requirements. The Manifesto for Agile Software Development is stated simply in four precepts:
- Individuals and interactions over processes and tools;
- Working software over comprehensive documentation;
- Customer collaboration over contract negotiation;
- Responding to change over following a plan.
Software projects are done in small, incremental steps. This enables new requirements and plans for future implementation to be integrated into the development process before a point of no return is reached. By using a lightweight development methodology, value and innovation can be maximized
Development is modular. Feature-Driven Development (FDD) is a practice where a product is delivered feature by feature over the life of the project. A useable release is completed and thoroughly tested before moving on to the next feature module. These small victories bolster team confidence and enthusiasm.
In this practice, communication among all stakeholders is ongoing; little emphasis is put on the strict adherence to a formal, staged process; and documentation is a work in progress, carried on by technical writers in parallel with development.
Team selection is also crucial. Highly talented players are imperative, and short, regular meetings are held daily or weekly — including regular meetings with the customer. Time outs are taken to review progress and plan for new directions.
The project manager is really a coach, and is responsible for facilitating communication among the players. Because all the players are “Stars,” facilitating team collaboration is at the heart of this practice.
An extreme methodology
One agile methodology that has become something of a buzzword is Extreme Programming. XP is intended to create a work methodology that can adapt to rapidly changing user requirements.
XP is characterized by rapid feedback, assuming simplicity (there is always an elegant solution to any design task), applying incremental changes and embracing design changes. Development is broken into iterations based on a small number of features. Iteration cycle time is measured in weeks.
A customer (or customer proxy) is on-site and always available. This is a person who will use the system. This enables constant communication of changing user requirements as well as feedback on feature functionality.
Activities include: coding, testing, listening (programmers know more about the desired features than the business aspects) and designing (creating a design structure that logically organizes the system.)
Practices
When implementing these development methods, it is important to keep certain practice standards in mind.
Fine-scale feedback:
- Pair programming — two programmers at one machine; code is reviewed as it is written.
- Planning:
- Business provides list of features and required functionality; User stories are written for each feature; Estimate of development team’s resources is made; Business decides what stories to implement and the priority (order) of development.
- Test-driven development:
- Unit tests are written by developers to test functionality while the code is being written and automated;
- Acceptance Tests (Functional Tests) are customer-specified, full-system scripts of user interface actions.
Continuous process:
- Continuous integration — changes are integrated daily;
- Design improvement;
- Small releases start with minimal core functionality, and add feature(s) each iteration.
Shared understanding:
- Coding standards — all code is written to the same standard, e.g. format;
- Collective code ownership — any developer can work on any part of the code at any time;
- Simple design — find the simplest (most elegant) solution and eliminate all extraneous code that doesn’t implement the current feature set;
Programmer welfare
- Sustainable pace — 40-hour work week that can be extended to one week of overtime, after which the project must be re-evaluated.
Moving targets
AP and XP attempt to resolve the challenges of changing user requirements for an in-progress project. They employ a development process that can respond rapidly to project modifications without disruption or extensive rework or redesign.
Documentation is living and tracks code development. It is not unusual for a technical writer to be part of an AP or XP project team. This leaves the application programmers to spend their time on code development.
Both processes are dependent on highly talented designers and communication. A siloed culture will fail at attempting AP or XP. Similarly, the customer must be actively involved and not wait to introduce new or modified features.
AP for BE
With constantly changing delivery opportunities, technology and business models, some aspects of AP and XP seem to be applicable to broadcast engineering. But many broadcasters believe traditional CMM and Waterfall techniques are better suited to the mission critical 100 percent reliability necessary for broadcasting, where a small failure can have a large business impact. The next T2D will examine how broadcast/media systems engineering can benefit from the best of both worlds.
