[SystemSafety] A Fire Code for Software?

[Les Chambers]

Steve

I'm with you Steve; our descendants will look back on much of today's
software as over-priced pulp fiction; poor quality, untrimmed and ragged;
redolent with crime, science-fiction, fantasy, romance and horror - authored
by amateurs. 

But let us not despair. Looking to the future, my preferred metaphor is:
software as literature; where ideas of permanent and universal interest are
expressed with enlightened meaning and form; creating something of value
that endures - authored by software developers who get it substantially
right on

the first draft. 

 

A while ago I gave this subject some serious thought, specifically what
separates the software engineer from the other ... commonly known as
software craftsmen.

Definition (?) of software engineering:

Applying a systematic, disciplined, quantifiable approach to concieving,
developing, operating and maintaining software intensive systems.

More at:

http://www.chambers.com.au/glossary/software_engineering.php

In this paper I examine the discipline of software engineering, from its
definition in the literature to the belief systems that make it work. I
examine the attitudes of mind it embraces (and the ones it discards), how
intuition must give way to formalism and how upfront analysis must replace
expensive downstream trial and error. Put simply, how we must think more
before we act.

 

Much of this paper is given over to the current imperfect situation where
the quality of software is almost wholly dependent on the individual and
collective skills of the project team - I cite Woody Allen who commented,
"95 percent of successful moviemaking is in casting" - one must resort to
tricky questions in job interviews. From my experience on the management
team of a fixed price software house my paper offers 24 searching questions
that may help you smoke out the "real" software engineers in a job
interview. For each question I explore the answers most frequently offered
by the craftsmen and the "right" answers you will often get from a software
engineer.

 

Summary (Refer paper, chapter 9):

1. What do you feel is your mission when you set out to capture user
requirements?

2. How do you solve wicked problems?

3. How do you make design decisions?

4. How do you go about innovating?

5. Can you describe your creative design process?

6. What is the secret to developing great software?

7. What is your view on the role of documentation in software projects?

8. Do you try to reuse code?

9. How you feel about working in a team?

10. The fox knows many little things, but the hedgehog knows one big thing.

- Archilochus (Greek poet, 680 BCE - 645 BCE)

Which do you think is the best approach, specialisation (the hedgehog) or
having a broad knowledge

of your application domain (the fox)?

11. How do you recognise and manage risk?

12. If your software has the potential to harm life and property, how you
make it safe?

13. Is software security something we should be concerned about? If so, how
do you secure a software

product?

14. When writing software, how do you manage your projects? Is planning a
valuable exercise?

15. Is formal scope definition useful? If so, how do you go about defining
the scope and extent of your

software product?

16. Are you happy to commit to an up-front cost? How do you estimate
software costs?

17. Are you happy to commit to a deadline for software delivery?

18. Are you an efficient software developer?

19. How productive are you?

20. What is software quality and how do you deliver it?

21. How did you learn to develop software?

22. How do you know that your work will delight your customer?

23. How you handle maintenance after your software is delivered?

24. Are your actions guided by any particular moral code? Do you feel
responsible for how your systems

are used?

 

The Way Out of the Crisis

The level of formality we use to build a system must increase in proportion
to its size.

We have already reached the stage where human beings are not capable of
manually (by intuition) building and validating a large system that is
correct by design. There is too much variation in attitudes and skill levels
in human beings to guarantee a predictable outcome.

 

My solution is to do what humanity has always done to deal with largeness
and complexity where consistency of outcome is critical. We increase the
level of formality in what we are doing and support construction with tools.
So my response to those who complain about "plug and pray" is, "try harder
because it is the only way out."

 

 I'd encourage people currently working on yet another industry standard to
accept that we have enough of them, what we need is better tools to assist
with compliance. Industry standards drive culture, tools ensure that
cultural imperatives are actually realised in end products.

 

Les

 

From: systemsafety
[mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of
Steve Tockey
Sent: Friday, March 9, 2018 5:01 AM
To: Andrew Banks; 'Andy Ashworth'
Cc: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] A Fire Code for Software?

 

 

Andrew,

I agree 100%. But I would actually take it even farther.

 

I am already on record as having said (referring to the software industry as
a whole),

 

"We are an industry of highly paid amateurs"

 

Claiming that one is an engineer simply because the words "software
engineer" are printed on one's business card are simply not sufficient. I
strongly recommend that we start a parallel effort to the recent "don't call
them bugs, call them defects" movement (Are you paying attention, Chris
Hills?). In this nw movement, anyone who uses the term "software engineer"
is required to:

 

A) provide a reference to a definition of the term "engineer(ing)" that has
been accepted by already-recognized engineers (e.g., Civil, Chemical,
Mechanical, Industrial, . . .)

 

B) Show how what they are doing on a day-to-day basis on their projects is
consistent with that legitimate engineer-accepted definition

 

The vast majority of people in this industry can't do either A) nor B).

 

 

What happens most of the time in the software industry is no better than
what I call "Resume Driven Development". Major technical decisions are not
made in the best interest of the organization, they are made based on what
looks good on the developer's resume.

 

 

Regarding this so-called "paradigm shift to agile methods", I claim that if
you really understand what "agile" means then you recognize that it is
nothing more and nothing less than a project management paradigm. And a
project management paradigm-any, including waterfall-alone is not sufficient
to either warrant calling "engineering" or assure delivery of reasonable
software at a reasonable cost and schedule. A true engineer would know when
a waterfall project management paradigm is and is not appropriate. A true
engineer would know when an agile project management paradigm is and is not
appropriate. A true engineer would make a decision on which project
management paradigm to use based on what provides the best return on
investment for the organization, and not what looks sexy on their resume. A
true engineer would also know that a project management paradigm alone is
not sufficient to assure delivery of  high-quality software in a
cost-effective way. Delivering high-quality software cost-effectively
requires:

 

*) a sane and rational approach to how the project is being managed

*) a sane and rational approach to how requirements, design, and
construction (coding) work is being done on the project

*) a sane and rational approach to how quality work (inspections and/or
other peer reviews, as well as testing) is being done on the project

 

 

My second book is not titled "How to Engineer Software" by accident.

 

 

 

Cheers,

 

- steve

 

 

 

 

From: Andrew Banks <andrew at andrewbanks.com>
Date: Wednesday, March 7, 2018 at 10:12 PM
To: Steve Tockey <Steve.Tockey at construx.com>, 'Andy Ashworth'
<andy at the-ashworths.org>
Cc: "systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: RE: [SystemSafety] A Fire Code for Software?

 

Hi Steve

 

And here is the rub:

 

>> My definition of "model based" involves creating and maintaining precise
specifications of semantics:

>> policies that need to be enforced and processes that need to be carried
out. 

 

It is the absence of this up-front work that is so prevalent in software
(and systems-) engineering. even in formal development environments,
engineers need to "get on with it" and let the requirements catch up.  Then
throw in the paradigm shift to more Agile methods and it gets even more
unpredictable.

 

But The Authorities seem to not care: Eg in the automotive world, despite
standards such as ISO 26262 there is no statutory requirement to follow a
formal development process. only "conformity of production" matters - and
the type approval process doesn't even mention the existence of software (or
involve any checking of how it came into being), and just concerns itself
with the physical characteristics of the vehicle.

 

Compare with civil engineering, where the detailed plans form part of the
planning process, and implementation is controlled by strict building
regulations, and independently monitored - and all components have to comply
with appropriate standards.

 

 

Regards

Andrew

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20180311/59dd5adc/attachment-0001.html>