Re: Interview preparation

Mark McDougall posted:

"Colin Paul Gloster wrote:

Someone in Green Hills Software had an article published in the June
2006 or September 2006 issue of "Ada User Journal" (which is currently
in the house but I can retrieve it tonight to post an exact quotation
tomorrow if requested) in which it is admitted that Green Hills Software
has been benefiting from not adhering to processes for more than the
ten previous years,
(snip)

I guess it all depends on the type of process you're talking about.

I was talking about processes such as formal review, simulation,
regression-testing, revision control etc.

Anyone who claims they have "benefited" from not adhering to these
processes is either a cowboy or a fool..."


Maybe.


From David N Kleidermacher, "Developing Reliable Software Rapidly",
"Ada User Journal", Volume 27, Number 3, September 2006:

"Abstract
Although there is significant evidence that following a structured,
comprehensive quality management process improves reliability of
software relative to the use of unstructured processes, these rigid
methodologies often cause a loss in efficiency, delayed time to
market, and frustration in the daily lives of software developers and
managers. This paper will provide advice in the form of guidance
statements that are compatible with the requirements of various high
assurance quality standards, yet are designed and proven to improve
efficiency of software development.

1 Introduction

Much commonality can be found in various quality management
(e.g. ISO9000 and CMMI) and safety critical standards (e.g. IEC-61508
and RTCA/DO-178B). [..] The traditional application of these
standards, although often yielding higher quality and/or safer end
products, often leads to stifling bureaucracy that slows time to
market and innovation.

[..]

6 Conclusion

High assurance development processes, such as that encouraged by
ISO/IEC quality standards as well as regulatory bodies that govern the
use of software in safety and security systems, is generally believed
to result in higher reliability software. However, an organization
that follows these processes to the letter is likely to get to market
later than an organization that develops the same product without the
overhead of following these quality standards. In this paper we have
presented a set of guidance recommendations, part of a process that
has been proven in use for 24 years at one of the leading
reliability-critical software development organizations in the world,
and have argued how these controls can actually increase developer
productivity and reduce time to market through the use of
methodologies that find software flaws faster and reduce developer
dependencies on each other and on productivity-killing bureaucracy."

From Kelly, "The Documentation Myth", "Overload", August 2006,
ACCU.org/var/uploads/journals/overload74.pdf
:

"[..]
In the worst case writing documentation becomes goal deferment . why
complete the code when you can complete the document? I worked on one
project that followed a rigorous ISO-9000 certified process. Despite
very
tight deadlines the documentation had to be kept up to date, as the
documents grew the development work slowed, morale fell and the
documents become more and more inaccurate. Even when they where
proof-read by others there was no check to make sure the document
actually described what was in the code. Increasingly the documents
said
what the managers wanted to hear and the programmers wrote the code
they way wanted to. So what are we to do about the documentation myth?
Which tool will solve my problem?
[..]
[..] And others were just
downright wrong, ISO-9000 for one.
[..]"

From an email on ACCU-General ( ACCU.org/index.php/mailinglists )
timestamped Thu, 2 Dec 2004 09:49:03 -0000:

"[..]

[..] I worked to this regime a few years ago. The company was
ISO-9000 and we where doing a project for privatisation.
This approach was well intentioned but didn't work, it increased the
burden all round and I don't think it removed that many bugs.

You have a problem.
I suspect your working as a sub-contractor, perhaps to the Government
or
some other large institution who are impressed by this.

[..]"

From an email on ACCU-General timestamped Thu, 2 Dec 2004 11:09:04
+0000 (GMT):

"[..]
ISO-9000 and we where doing a project for privatisation.
This approach was well intentioned but didn't work, it increased the
burden all round and I don't think it removed that many bugs.

That sounds about right, especially given you said ISO-9000. From my
dealings with it, its not about making anything better, or improving
the
quality, you just need a process, however useless that process is, and
to
follow it.

So "We print this form out, tick the boxes and sign it" is fine from
an
ISO point of view, it doesn't matter that it might prove nothing. Its
all
about process.

I have a very low view of ISO-9000, the amount of smoke and mirrors
that
is put on for audits is just a joke."

In "Re: first job, how to avoid wtf companies?" timestamped
06-22-2006, 5:14 PM on
HTTP://forums.TheDailyWTF.com/forums/permalink/78413/81920/showthread.aspx
, someone wrote:
"[..] The problem you'll have, besides limited choices, is gauging the
actual level of WTFedness of a company. They'll all lie to you, and
some of them are professional liars. Here are some guidelines:

* Your last choice should be big consulting firms and government
contractors. They'll claim to be ISO9000 or CMM level 3, but their
actual software engineering methods tend to be whatever Microsoft
Project and Powerpoint do. Almost as bad is when you land on the rare
project that does it by the book. The "book" is usually the waterfall
method, which has been discredited for 20 years.
[..]"

From the editorial of "CVu" Volume 15 Number 4:
"[..]
Each small step is easier to define and more
likely to succeed than a drastic change, and success
breeds success. Making some effort to document
and communicate the creative works of a software
development group is worthwhile for a number of
reasons, however. It.s something your organisation
probably ought to do. If you get there first, with a
lightweight process that still gives the business what
it needs, you might avoid having a process
mandated without such consideration for the
realities of software development.
[..]"

From "Professionalism in Programming #31: Code Monkeys (Part Two)",
"CVu" Volume 17 Number 2:

"[..]
Last time we began a high-paced stroll through a gallery of collected
programmer stereotypes. We.re looking at individual developer
attitudes,
to see how they can drastically affect the quality of the software we
write
and how they affect the whole development team.
In this concluding article we.ll finish the tour, and see what makes
the
best type of programmer. Brace yourself: here come more Code
Monkeys...
[..]
7. The Planner
The Planner thinks about what he.s doing so much,
the project.s been canned long before he.s started
writing any code.
It.s true, you must plan up front and establish a
cohesive design, but this guy forms an impenetrable
cocoon around himself and refuses any contact with
the outside world until he.s finished. Meanwhile
everything.s changing around him.
Terminally educated, the Planner studies and reads a lot. A common
subspecies is the Process Weenie; he knows all about the .proper
development process., but is weak on hitting deadlines or getting
anything
done. (Process Weenies eventually become middle managers, and then get
fired.)
Strengths They do design. They do think. They don.t hack out
thoughtless
code.
Weaknesses When a Planner sets to work there is a very real danger of
over design. He tends to create very complex systems. Planners are the
key cause of analysis paralysis . where development gets more focused
on methods and modelling than on prototyping and creating a solution.
The Planner likes to generate endless documents and call meetings
every other
He spends ages thinking, and not enough
time doing anything. He knows a lot, but it
doesn.t all make the leap from theory to practice.
What to do if you are one It is important to
create careful designs up front, but consider
incremental development and prototyping as
methods to verify your design. Sometimes you
can.t commit to a design until you.ve actually
started to implement it. Only then will you appreciate all the
problems.
Try to establish a better balance of planning and action. Console
yourself that it.s better to spend too long designing than to write
awful
code . the latter is far harder to fix.
How to work with them Ahead of time, agree all milestones and
deadlines
for a Planner.s work. Throw in a design complete milestone; they.ll be
happy that it has been recognised as an important task, and encouraged
to complete their design work on time. This is usually enough to
crystallise a Planner into action.
Avoid meetings with a Planner. You.ll spend an hour arguing about how
to decide the agenda.
[..]"

From Griffiths, editoral: "The Power of Inertia", "Overload", February
2007,
ACCU.org/var/uploads/journals/Overload77.pdf
:
"[..]
[..] they will cling to
processes and procedures that are demonstrably against their interests
until
there is sufficient pressure to cause a change.
[..]"

From Sebright, "Up Against the Barrier", "Overload", October 2006,
ACCU.org/var/uploads/journals/Overload75.pdf
:

"[..]
Let.s explore what the barriers might be, with an attempt to
categorise
them:
Process
* Very bureaucratic change process
[..]"

From Asproni, "How to Shoot Yourself in the Foot. In an Agile Way.",
"Overload", February 2006,
ACCU.org/var/uploads/journals/overload71-FINAL.pdf
:

"[..]
Focusing Too Much on the Process
and not Enough on the Product
This is typical of a team using a specific process for the first
time. To a certain extent it is normal: after all, when you are
learning something new you need to focus on it to see if what you
are doing is right or wrong.
However, when the team starts to think along the lines of .the
code is not good enough, maybe we are not doing enough <put your
preferred practice here>. too often, it could be a sign of something
else going wrong.
Of course, good teams think about the process, and change it to
fit better their current situation, but they spend only a fraction of
their time doing that. In my experience, when too much time is
spent on the process, it is a sign that the team is looking for a
scapegoat for their shortcomings: blaming the process is easy and
safe, since nobody is going to be held responsible for failure.
[..]"

From Rob Hughes's review in "CVu" issue 15-1 on
ACCU.org/index.php/book_reviews?url=view.xqy?review=s003342
of Murray Cantor's "Software Leadership":

"[..]

[..] For example, the author elegantly explains why the heavily
controlled processes of the past have failed; trying to force a linear
model onto a non-linear process is doomed to fail.

[..]"

In Mike Higginbottom's review of Jim Highsmith's "Agile Software
Development Ecosystems" in "CVu" 15-6 on
ACCU.org/index.php/book_reviews?url=view.xqy?review=a003491
it is written:

"[..]

[..] He talks about replacing process and control with freedom and
discipline, but the pervasive thread running through all this is an
emphasis on people and the way they think and behave. This is the
central message of the book. Process won't save you; but your people
just might if you let them.

[..]"

From Chris Hills's review of Rex Black's "Managing the Testing
Process" in "CVu" 15-6 on
ACCU.org/index.php/book_reviews?url=view.xqy?review=m003498
:

"This is a brave title for a book. If there are any words that
programmers run from they are 'managing', 'testing' and 'process'!
[..]

[..]"

From Chris Czarnecki's review of Alistair Cockburn's "Agile Software
Development" in "CVu" 14-4 on
ACCU.org/index.php/book_reviews?url=view.xqy?review=a003236
:

"[..] Agile software processes are built on four core values:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
[..]"
.

Relevant Pages

  • Re: Opinions re: MCU vendors [long]
    ... I'm looking at a couple of different parts from Atmel ... you *know* a quality product when you see it. ... you verify that it meets the other design specifications. ... Documentation for a reference design using that same component ...
    (comp.arch.embedded)
  • Re: Learning embedded coding, which uC?
    ... >>>Reviews do increase the quality of a design, ... Had there been a thorough enough design review I ... I am not saying documentation is not a good thing. ...
    (comp.arch.embedded)
  • Re: Improving the first contact with Ada
    ... time writing quality software and not enough doing marketing. ... for documentation, documentation should come first! ... Not graphical design! ... What can you expect from someones who run away from a graphical design and   ...
    (comp.lang.ada)
  • Re: Forth is broken by culture?
    ... At some point the design provides some clear idea of what ... Forth" which discusses design and documentation processes for Forth ... review process, what your specifications look like, etc. ... If you do your Forth code right the only tool you need for static analysis ...
    (comp.lang.forth)
  • Re: How many of your jobs are like this?
    ... Megawatt power designs one day, ... documentation easier, ... if the windows are *open* to much and don't present enough ... "back pressure" to keep wind from pushing HOT AIR back into the ...
    (comp.arch.embedded)