The Iowa Caucus and the Minimum Viable Product
Tuples From iOS Developer Tips Weekly

The Iowa Caucus and the Minimum Viable Product

While the political fallout from the Iowa caucuses will reverberate for quite a while, a primary cause, the failure of a critical mobile app and its backend software brings up many issues that are not political. At the heart of the story is one question: how did that app ever see production? 

It is still early to tell exactly what happened. The New York Times and The Verge both reported on app developer Shadow's deficiencies in building the app. The primary of those is a short development cycle of two months, but a lack of quality assurance plagued the app as well. Many reports give information that Shadow did an end-run around Apple's app vetting process for iOS, and the standard distribution system of the App Store, in favor of a more complicated process. From the reports, it may have been via the TestFlight and TestFairy Beta platforms as The Verge reports

As an App developer, author of iOS development courses for LinkedIn Learning, and a CIO of a medical device company, all of this brings up concern for me. There has been a movement for more than a decade towards the minimum viable product or MVP, championed by Eric Ries in his book The Lean Startup

"A minimum viable product (MVP) helps entrepreneurs start the process of learning as quickly as possible. It is not necessarily the smallest product imaginable, though; it is a fast way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort. (p. 93)"


The idea behind MVP is simple. Build something that barely works, put it out on the market as a production app, and get feedback to know what to fix, what to abandon and what to add to the product. It is sink-or-swim testing of a product, but it also put the experiment of a product in the hands of the consumer. It leads to faster and cheaper development cycles. MVP has been championed by many, including marketing guru Seth Godin. Godin and others use MVP as a laudable effort to prevent perfectionism in entrepreneurs, which keeps the product from launching at all. 

MVP does have its place when the risk and cost of failure are low. However, when the risk and expense of failures are high, it has no position in development. Medical devices, aircraft, or the political future of any nation do not belong to a buggy app that gets corrected after a failure. Such applications and products must be thoroughly tested and validated: there is no room for failure. 

Again we do not know the whole story this early. The reporting gives a timeline of fewer than two months to build and launch the applications to do the accounting for the Iowa caucus. Most companies don't get their websites up that fast. While no one cannot tell if the production app was MVP, incompetence, or a simple rush job, they all have a similar result: a Sloppy application that has a high probability of leading to expensive failures. 

That's the significant objection to MVP: it leads to sloppy results. MVP is a balance between combatting perfectionism, using the market to test a product cheaply, and fast implementation. The cost is crappy and possibly dangerous products. As proponents might tell you, the key is the V - viable. Yet when I hear of MVP in most context on podcasts and articles, viable means barely working. Ries writes: 

"We do everything wrong: instead of spending years perfecting our technology, we build a minimum viable product, an early product that is terrible, full of bugs and crash-your-computer-yes-really stability problems. (p.4)"

For me, especially one whose business is medical diagnostic components, that's not good enough. Outside my FDA and ISO obligations, viable must also mean all high and medium risks are identified, then mitigated or eliminated. It is wrong from a moral sense. I do not want to kill anyone. It is wrong from a business sense as my reputation of a vendor of critical components if I do not deal with these risks upfront and before I ship even prototype components to customers. Not only medical devices should have design controls. 

The irony, of course, is before MVP is launched, there can be beta tests, using platforms like TestFlight and testFairy. Beta testing has users aware they are testing unproven software or an unreliable product. It is a condition of using the beta to identify bugs. Sadly Shadow saw these beta test platforms as places to launch the app. 

The Iowa Caucus was a high profile failure, and while nobody died because of it, political fortunes in the U.S. will be affected for a long time. What the repercussions are are still to be seen. In the wake of this and other failures, fast-cycle production and MVP should die for high-risk products to prevent even worse events from happening. 

Steven Lipton is the Chief Information Officer of Scientific Device Laboratory, a medical device and diagnostics manufacturer specialing in microscope slide printing and TB diagnostic products. Steve is also the author of many courses for LinkedIn Learning including SAP Business One Essential Training and SwiftUI Essential Training. He is also the author and host for the weekly series iOS Development Tips Weekly on LinkedIn Learning.



  

要查看或添加评论,请登录

Steven Lipton的更多文章

  • Predicates and Predicate functions in HANA

    Predicates and Predicate functions in HANA

    #Bizoneness: Over the last few newsletters, we reviewed functions in HANA and their SQL equivalents. Our last in this…

  • LucaERP part 5: Building A Form

    LucaERP part 5: Building A Form

    In this series of biweekly columns, we're building an ERP from scratch, starting with the general ledger. We've learned…

  • BizOneness: Aggregate Functions in HANA

    BizOneness: Aggregate Functions in HANA

    #HANA #Bizoneness Over the last few newsletters, we've been looking at the basics of HANA. This time, I'd like to look…

  • LucaP: The Anatomy of User Interfaces for ERP

    LucaP: The Anatomy of User Interfaces for ERP

    #LucaP In the last installment of building the LucaP ERP, we discussed the part of the general journal. We have yet to…

  • Bizoneness: Common SQL and HANA types, Operators, and Functions

    Bizoneness: Common SQL and HANA types, Operators, and Functions

    Bizoneness: Common SQL and HANA types, operators, and Functions #Bizoneness #HANA Two weeks ago, I wrote the first of…

    1 条评论
  • LucaP ERP part 3: Adding General Journal Entries

    LucaP ERP part 3: Adding General Journal Entries

    #LucaP *Note:As I've gained a few followers and subscriptions in the last few weeks, I want to remind everyone that I…

  • Bizoneness: Introducing HANA

    Bizoneness: Introducing HANA

    #Bizoneness While I had planned something about the General Ledger for this newsletter, circumstances changed, so I'll…

    3 条评论
  • LucaP ERP part2: The Chart of Accounts

    LucaP ERP part2: The Chart of Accounts

    #LucaP #ERP In the ERP application, we have established credits and debits on a ledger with the five major accounts…

  • The Bizoneness Migration Guide

    The Bizoneness Migration Guide

    #Bizoneness Data migration is taking data from one source and merging it into another source. If you're very lucky, it…

  • LucaP ERP Part 1: The Basic Equation

    LucaP ERP Part 1: The Basic Equation

    #LucaP How do you start to understand the workings of an ERP system? By making one. In this biweekly column, we’ll make…

社区洞察

其他会员也浏览了