One of the big-three reasons commonly cited as cause for going “more IP,” and eventually “all-IP,” is the notion of “service velocity” — new-tech talk for getting more stuff to market more quickly. As in, ditching the time-tested “one new thing every 18 months” plan, long an unfortunate shackle of the set-top-based digital video world.
Rather than trudge yet again through the depressing realities about why things take so long in today’s world, let’s look at what puts the “velocity” into new-service rollouts.
This probably doesn’t come as a big surprise: Turns out it has a lot to do with the tsunami of software-based everything that’s making the workplace, and people, more efficient.
Talk to the people whose work it is to bridge between now and next, and specifically service velocity. They’re almost always IT/information technology people. Chances are high that you’ll hear two terms pop up again and again: Agile programming, and waterfall programming. “Waterfall” is old world; “agile” is new world. Proponents on each side tend to snark on the other.
Here’s some examples, from recent notes: “Waterfall is a disaster … you get these designs that aren’t influenced by reality.” And (puffed out with pride): “We run an agile development shop.”
My personal favorites: “Agile is the only way you can keep track of all the sh#t that’s going on in the network and at the end points,” counterpointed by “Agile, tiger-teams, it’s all a bunch of crap.”
“Waterfall” coding goes like this: You need to roll out a new video feature. After it’s designed, by the design team, it goes to the quality assurance team. Then to the solutions, integration and test team. If that’s all good, it gets released. Waterfall time is measured in double-digit months - and heaven forbid something changes along the way.
(Things that take a long time always remind me of a favorite joke. MSO to vendor: “Great! When can I have it!” Vendor: “In six months.” MSO: “Six months from when?” Vendor: “From every time you ask.”)
Agile programming is different. It splits the coding workload into chunks, which are constantly shipping, written by small teams that work in twoweek “sprints.” Changes are assumed, meaning that time is reserved to add stuff in, if requested.
None of this is new, by the way. In the world of computer science, it’s an old saga. A Google search on “agile v. waterfall programming” returned 540,000 results. Books are written on it; seminars are taught about it. It’s new to us because software is eating the world - and to survive and thrive, we need to know what and how software eats.
________________________________________
Stumped by gibberish? Visit Leslie Ellis at translation-please.com or multichannel.com/blog.
