Re: Interesting article ZDNet re informal software development quality

[Brian Utterback <brian.utterback () sun com>]

Bruce Ediger wrote:


On Thu, 8 Jan 2004, George Capehart wrote:

 


security.  *That* is part of the requirements.  If it's not a
requirement, then the system owner signs off on it and accepts the
risk.  Developers are *not* risk managers.  I agree 1000% with your
position that part of good security is balancing the cost of the
process and controls against features and risk.  But the decision about
how much residual risk will be accepted is up to the business owner of
the system, *not* the developer . . . It's a business decision, not a
technical one . . .
   



But in the context of the "interesting article" that lent its title
to this thread, the "system owner" and the developer roles often
belong to the same person.  Or nobody in particular has the "system
owner" role.

Even in a corporate environment, the business owner of some system
is often so lacking in tecnical savvy, or is more interested in
jockeying for power than in actual managing.  Risk managment devolves
onto the developers in most or all corporate development.

Just like failing to acknowledge the tensions between aspects of
"quality", saying that a "business owner" or "system owner" of
a system should perform risk management, and the developer should
not, denies the reality of most software development.  Holding such
a position makes you part of the problem, not part of the solution.
 

It is certainly the case that risk management is not the job of the 
developer.  That management is
not technically savvy is not important, it is still the job of 
management to make the informed
decisions. It is the jobs of the developers to make sure that the need 
for a decision is communicated
and that management is informed, at least as to the technical aspects of 
the decision.


The issue of who makes the decisions in the case of open source 
development is more intriguing,
but for the standard commercial model the process is (or should) be well 
understood. It is the same
as the process for any type of manufacturing, namely keep management 
informed of the problems,
provide data and explanations and let management do what it is supposed 
to do, manage.


This system does not always work, sometimes there are breakdowns in 
communication, leading to

spectacular failures.  But by and large it works and works well.

As previously stated, security is part of the requirements. Management 
will make it a requirement and
give it more weight in subsequent decisions when it becomes important to 
them. It will become
important when either it becomes important to the consumers, or they are 
made libel for mistakes.
Until then, security is not cost effective and will not be a priority. 
It is only given any attention at all
under the current circumstances because of the bad publicity of having a 
security problem.


--
blu

Lesson from the blackout of 2003:
The power grid is THE most critical infrastructure, upon which all 
others depend, and nobody really knows how it works.

--------------------------------------------------------------------------------
Brian Utterback - Solaris Sustaining (NFS/Naming) - Sun Microsystems Inc.,
Ph/VM: 781-442-1343, Em:brian.utterback-at-ess-you-enn-dot-kom