Risk Management
AC for the normal reasons.
The author identifies some "risks," and I have some thoughts about them:
1. "Bug Swarms" - There are other good ways to manage this risk. Unit testing and proper QA procedures come to mind. It's important to realize that in DevOps, QA is just as rushed as development, and simply can't cope with insidious bugs at all, let alone multiple bugs at once.
2. "Useless Software" - So bug-riddled, poorly functioning software is useful in some respect? However, let's limit our discussion to some imaginary, properly functioning but unwanted feature of a software package. In cloud-cuckooland, users effectively convey their dissatisfaction to the developers, who immediately re-imagine the feature, push it to production, and it works so well that users carve marble statues of the developers in the foyer during all the time they save. Now, over to the real world, where the developers never imagined the feature. Management imagined it, with the help of a tea-leaf diviner called a "usability consultant;" its inception involved focus groups, and a great deal of money. The UX team hears rumblings of dissatisfaction, but since they're privy to the development process, they conceal this for a while, hoping it'll go away, because they're the messengers that will be shot by the manager championing the feature. After a month or so, the complaints keep coming in, and UX informs the manager, who finds out this code now has multiple dependencies because the whole program is constructed like a painting made by throwing buckets at a canvas while standing in jet engine exhaust, and the crappy feature remains indefinitely, or at least, for a very long time.
3. "Stymied Innovation" - My experience is that users expect consistency in design rules, a modicum of sense applied to the organization of features, and software that works. Then, once they have it, they desperately hope that nobody will seek to "delight" them by screwing with it. Users are especially frustrated when those delightful innovations are not uniformly applied across the UI. A recent example of this is Windows 10 Mobile.
4. "Budget Overruns" - OK. Supposing I have 1000 units of currency to budget for the month, and I decide the following: I will place this money in a pool, and when I decide that I want something, I will create a new budget for exactly the cost of the item I want. That way, I'm more likely to decide to spend it! I will try to avoid multi-purpose items, preferring to purchase multiple single-purpose items that are less expensive per unit. Each time I go to the store, I will purchase only a few items at a time, to ensure that, when I use them, it's easy to figure out which ones are not satisfactory. When I make a poor purchasing decision, I don't worry too much, because it's a learning experience!
5. "Schedule Elongation" - It makes sense that this would be a problem. After all, if I can't construct a budget and adhere to it, how could I possibly construct a schedule and adhere to that? And, you know, there's always "more hardening to do." Like ripping your hardcoded AWS keys out of the application binary. Until DevOps happened, I couldn't even imagine something so absurd.
Biting the hand that feeds IT
