Jon,

As an observer of software "engineering" since its inception in 1968 (my first 
job as a programmer was that fall, and that spring/summer is when the NATO 
conference first coined the phrase), I can and will (braggadocio here) state 
that most software CANNOT be engineered, precision or otherwise, and all that 
we have learned in the past 52 years in both computer science and software 
engineering is essentially irrelevant to the production of application level 
software.

The protocols that ensure cat photos are scattered into packets traversing vast 
segments of the Internet to be reassembled and presented on you phone in real 
time, is an example of the minority of software that can be engineered. The 
vote counting app _could not have been_.

The difference is that the first replicates, in software, a deterministic 
machine with limited variables, all of which can be known and quantified, 
limited relations among variables, all of which can be known and stated; and 
the second one is a complex system where variables and relations are highly 
dynamic, idiosyncratic, and, often, quite literally unknowable.

I just completed a sixty-page essay on this subject "Why Programming is Hard 
and Software Development is (Mostly) Impossible" that addresses this issue. If 
you would like to read, let me know and I will send you a link or the paper.

Making things worse is the superstructure around software development — all the 
methodologies, all the frameworks, all the management levels, all the practices 
that supposedly guide/govern the process of developing software.

Icing on the cake, is attitude. Those that contract for software EXPECT that 
the project will fail and/or that what they get will be a pale imitation of 
what they wanted, full of bugs and inconsistencies. The development team also 
EXPECTS the project to fail, for different reasons, but fail nevertheless.

And roughly 90-percent of the time both sides have their expectations realized. 
(60-65 % of projects started are abandoned without any delivery, the other 
20-25 percent are those pale imitations over budget and taking twice the time.)

One more factor - the game is rigged. Those that might actually be able to 
deliver reasonable software applications are not allowed to play in the game. 
Acronym and Shadow came into existence because people in Hillary Clinton's 
campaign thought they saw a way to make money and used their connections to get 
established and make contracts. The "bid" process was laughable, the specs 
being written such that no one but Shadow could comply and in a time frame that 
Microsoft, et. al. were not able to respond adequately.

Half a billion dollars were spent on the Obamacare website and another 
half-billion to get it to work after the initial failure. A startup team of 
Web-developers built the site with full functionality, including calculating 
subsidies (supposedly the hard part) in a week. Their site was demoed on Sixty 
Minutes. But they would never have been allowed to bid on the original project 
because they did not meet Federal procurement guidelines which were rigged to 
very large companies most of whom have a remarkably long history of spectacular 
failures on past projects.

Frothing at the mouth so much, am at risk of dehydration.

dave


On Fri, Feb 7, 2020, at 8:54 PM, Jon Zingale wrote:
> My intention in drawing attention to critical application
> development is an attempt to deepen the discussion
> around 'apps' and rhetoric. In the discussions around
> app usage in the democratic primaries, the target appears
> to be the vulnerability which exists today because
> programmers today are a bunch of python hacks who
> never read Knuth. Yet, not a single Friam mother-church
> meeting passes without a discussion of the precision
> engineering embodied in our Porches, Teslas, or iphones.
> 
> Of particular interest to me in directing this rhetorical frame
> are the so-called-on-wikipedia FBI-Apple encryption dispute 
> <https://en.wikipedia.org/wiki/FBI%E2%80%93Apple_encryption_dispute>
> and the Target corp data breach <https://arxiv.org/pdf/1701.04940.pdf> of 
> 2013. In the first case,
> the federal government is confronted by the reality that a
> phone manufacturer *can* in fact make cryptographically
> challenging hand held devices. Further we can use this
> powerful technology for sending our family cat pictures
> which arrive at their target destinations almost without
> fail and near instantaneously. There is a sense of *justified*
> *indignation* when the cat photo takes more than a second
> to be delivered. The state-of-the-art is such that we *can*
> have nice things.
> 
> In the second case, a data breach is exploited in the POS system
> of big box corporation which sells mostly useless things. Next,
> a public rhetoric emerges similar to the rhetoric I am witnessing
> here with the democratic primaries. Instead of pointing out that
> Target corp doesn't consider our privacy a critical concern, we
> speak of how impossible it is to have privacy and how vulnerable
> we feel because Target corp is a critical institution.
> 
> Jon
> 
> 
> ============================================================
> FRIAM Applied Complexity Group listserv
> Meets Fridays 9a-11:30 at cafe at St. John's College
> to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
> archives back to 2003: http://friam.471366.n2.nabble.com/
> FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove
> 
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
archives back to 2003: http://friam.471366.n2.nabble.com/
FRIAM-COMIC http://friam-comic.blogspot.com/ by Dr. Strangelove

Reply via email to