Cloud Broadcasting - Agile Development
In the previous Cloud Broadcasting article, we took a very brief look at cloud security and its advantages over traditional datacentre systems. In this article, we delve further into Cloud Born systems and investigate the new requirements for software development and upgrades in broadcast software services.
Software development has progressed in leaps and bounds over the past few years to become a respected professional discipline. The processes and structures around programming are much better defined and implemented to give stable reliable services.
Low Level Software is Efficient
Twenty or thirty years ago, developers would write in low level languages such as assembly or C, and their mindset was heavily tied to the underlying hardware and operating system.
Low level software development has its advantages, it’s very efficient in terms of execution speeds, memory and disk space use. A program coded in assembly language or even C will execute much faster than today’s offerings of Node-JS or Java. However, they’re incredibly difficult to code, maintain and the resulting executable code is tied to a specific processor family such as Intel’s x86.
Holy Grail of Development
High level languages such as Java and Node-JS abstract the hardware and operating systems away from the developer and with their vast libraries are easier to program, they are slower than low level languages but the speed of processor and memory resource now available significantly outweighs the hit on performance.
The holy grail of software development is re-usable code, that is code that has already been used in another program – the code is more reliable as it’s proved it already works, and it doesn’t need to be re-written. Although code re-use is technically possible in low level languages, it becomes easier as we move to higher level languages. Code is compiled into libraries and is built by in house teams, or bought from third party providers, thus reducing development times even further.
The two samples of code both print "Hello, World!" to the screen, the low level assembly code on the left is significantly more complicated than the high level Java code on the right.
Re-usable code reduces the risk in software development, and as a library has proved its worth it can be used again with confidence.
Unknowns Kill Delivery Times
Software development was traditionally provided using waterfall methods of project management, the whole project would be scoped out, planned and designed before a single line of code was written. The process was slow and the specification would usually be out of date before coding started.
Complexities and unknowns in a system make development times notoriously difficult to predict, especially on big projects and infrastructures. Waterfall methods of project management make the problem worse as they don’t adequately consider the risks, and a project can often over-run in its first week of execution.
Agile is Lightweight
Agile software development was devised by a group of 17 developers who met in 2001 in Utah to design a system to overcome the short comings of waterfall project management. The Manifesto of Agile Software Development resulted, a document to encourage lightweight development. The manifesto promoted people interaction amongst software teams and users, focused on well written working software instead of pages of documentation, and would respond to user-change quickly and efficiently.
Agile delivers functions that are tested quickly, and prioritizes new features as the demand of the users change. This is a very important change in the mindset of software delivery, for developers, end users and business owners.
Development of functions is split into small time periods, referred to as “sprints” that usually last two weeks. At the end of a sprint the development team will have provided a function that can be released into the market place and made available to the end user. Feedback is quickly gathered, bugs identified and the impact on the business assessed.
The process of releasing code involves moving the release to an intermediary staging server so final tests can be performed before the code is made live.
One of the most important aspects of Agile is the connection between the development teams and the business users. With the waterfall method, the project manager would give weekly updates to the management team advising of the progress of development, a process that could go on for many months or even years without any code being demonstrated. When the release date finally happened, the code was often met with mixed reviews as many of the delivered features were either misunderstood, miscommunicated or just out of date.
Minimum Viable Product
Using Agile, a new software design will start with a list of required functions and then prioritized with product managers and business owners. The initial functions would be developed with the intention of providing a minimum viable product (MVP), this is the release that provides the minimum number of functions for the software to be useful. The program is tested within a matter of weeks and feedback quickly gathered.
During the life cycle of the product, many stake holders will have a view on which features take priority and which are the most important. Sales people, support engineers and development managers have all tried to change the course of a development team in the past to get a feature implemented which they think is a priority, often with disastrous consequences and annihilating release dates. With Agile, anybody requiring a change must create a user-story, a simple short specification of their feature and put it in the product-backlog.
Pre-Testing with Staging Servers
At planning meetings, product and development managers, and business owners will meet and evaluate the backlog to agree the priority of the next functions to be developed and released. Due to the dynamically changing business demands functions that have been a priority in the past can be moved to the back of the queue, a frustrating outcome for some stake holders, but a massive bonus for business owners who can look at the bigger picture and determine the best outcome for the whole business.
New functions are released to a staging server, a near-copy of the live service for pre-production testing. Once the test vectors have passed the software is pushed to the production servers and made live. Prior to Agile, software releases were very irregular, maybe six or twelve months apart, causing all kinds of stress and instability to the system. Releasing software every two weeks makes the whole system much more stable and reliable, and if a release proves to be buggy or problematic it can be easily rolled back.
Cloud computing benefits greatly from high-level language coding and Agile development, and collaboration is a key concept amongst developers and end users. Agile development enhances the cloud ethos of fast time to market and reacting quickly to customer demands.
You might also like...
Designing IP Broadcast Systems - The Book
Designing IP Broadcast Systems is another massive body of research driven work - with over 27,000 words in 18 articles, in a free 84 page eBook. It provides extensive insight into the technology and engineering methodology required to create practical IP based broadcast…
Demands On Production With HDR & WCG
The adoption of HDR requires adjustments in workflow that place different requirements on both people and technology, especially when multiple formats are required simultaneously.
If It Ain’t Broke Still Fix It: Part 2 - Security
The old broadcasting adage: ‘if it ain’t broke don’t fix it’ is no longer relevant and potentially highly dangerous, especially when we consider the security implications of not updating software and operating systems.
Standards: Part 21 - The MPEG, AES & Other Containers
Here we discuss how raw essence data needs to be serialized so it can be stored in media container files. We also describe the various media container file formats and their evolution.
NDI For Broadcast: Part 3 – Bridging The Gap
This third and for now, final part of our mini-series exploring NDI and its place in broadcast infrastructure moves on to a trio of tools released with NDI 5.0 which are all aimed at facilitating remote and collaborative workflows; NDI Audio,…