Slow Down And Don’t Break Things

When it comes to skyscrapers and bridges and power plants and elevators and the like, engineering has been, and will continue to be, managed partly by professional standards, and partly by regulation around the expertise and duties of engineers.  But fifty years’ worth of attempts to turn software development into a legitimate engineering practice have failed.
…
By the 1960s, large national-defense systems were largely managed by computers.  But the creation of such systems was a disaster — almost everything was delivered late, over budget, and with unnecessary complexity.  Late in the decade, the NATO Science Committee sponsored two conferences dedicated to establishing an engineering approach to software creation.  The 1968 conference report shows that the notion was still aspirational:
The phrase “software engineering” was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering.
Commercial applications meant to service ordinary people, from inventory control to airline reservations to banking, needed to be reliable.  Programming merely involved implementation.
Software-engineering trends came and went during the ensuing decades.  Structured programming paradigms of the 1960s, meant to make software development more predictable and less risky, gave way to the object-oriented paradigm of the ‘80s and ‘90s, meant to make programming better mirror the business processes it facilitates.
Meanwhile, the overall challenges of software engineering became more familiar and more entrenched.  A decade after his 1975 intervention The Mythical Man-Month: Essays on Software Engineering, Fred Brooks lamented that little had changed.  In response, he proposed incremental development, or prototyping.  Today’s software development is iterative, and for good reason:  Software wasn’t ever really akin to manufacturing and construction, where changes were difficult or impossible after initial implementation.
…
So, what happened?  The personal-computer revolution, for one.  In the 1960s and ’70s, computers were expensive and scarce.  They were confined to research, in governmental, corporate, and industrial contexts.  But with the rise of the microcomputer in the late 1970s, anyone could own, use, and program one.
—     Ian Bogost
From the article:  “Programmers:  Stop Calling Yourselves Engineers“
Appearing in:  “The Atlantic“;  dtd:  5 Nov 2015
The specific article is located at:  https://www.theatlantic.com/technology/archive/2015/11/programmers-should-not-call-themselves-engineers/414271/
[Prior to the “personal computer”, a computer cost in the millions of dollars and computing cycles (time) was expensive, so companies were “willing” to pay “engineers” to know what they were doing and keep running costs down.  Now that computers are relatively inexpensive and cycles are virtually free, there is a great distance between what companies expect delivered and what they are willing to pay programmers / engineers to deliver the expected.  It should also be noted that not all “great” programmers make “great” engineers, nor do all “great” engineers make “great” programmers.    —    kmab]
.
On This Day In:
2022	Slow Down And Don’t Break Things
2021	How Many Democracy Loving Conservatives Are In The Senate?
	The Fighter Still Remains
2020	Love And Charity
2019	Tomorrow Is Valentine’s Day
	Inverted U Curve
2018	Still More Prejudice
	A Well Trod Path Of Hopes, Expectations And Surprise
2017	…And With It Civilization
2016	Just Like My Mother
2015	All Omissions Are Mine
2014	Precise Order
2013	Uh, No. Not Really…
	Deep Regions
2012	A Pre-Valentine’s Day Message
2011	Easy Like Sunday Morning
	May I Have A Little More, Please…
2010	Valleys and Peaks

Advertisement