Re: tunnel vs open a hole

["Marcus J. Ranum" <mjr () ranum com>]

George Capehart wrote:
> *They* don't care, and the only 
> thing *their* managers care about is product/system availability and 
> sales numbers.  They don't have a clue what's going on in the pits, nor 
> what affect their decisions have on the morale of the coders . . .

First off, this is all a painful topic for me, so sometimes I come across
a bit more "attitude" than I probably should. Secondly, I'm in the weird
position of having been, at one time or another: coder, project team lead,
QA tester, technical presales support, system architect, VP of engineering,
CTO, and CEO - all at companies that produce software products. At various
times I have felt every one of the pressures that we're complaining about,
and have often applied them, myself. So I'm terribly conflicted about a lot of
these issues because I'm not just able to take more than one perspective -
I've seen 'em all...

That said, I spent 3 years as the heartless CEO or CTO who tortures
engineers to "get it done NOW at whatever the cost."  Sometimes it's
because I know that the company won't survive if it doesn't get done,
and other times it's because the bloody software is way behind schedule.
The first case is a failure of management: management didn't allow long
enough to get things done - or competitors moved too fast. Oops, that's
life in the food chain. But even a mouse struggles when a cat grabs it.
The second case is a failure of a more subtle sort. I can no longer enumerate
the number of times I have sat in meetings with engineers and engineering
managers and said, "this is what we need to do, and here's how we need
to do it, and here's how it needs to work. how long will that take?" And then
you get an answer from the engineers and you _add_ a safety margin to
that, and build that into your business plans. OK, so the engineers said
March, we'll start marketing in April, and plan to get sales on it in May.
And when April rolls around, the code still isn't even in QA. Not because
of "feature creep" - hell - I can't COUNT the number of times I slipped features
from one release to the next because they didn't get done in time and I had
a $150,000 ad campaign starting that I couldn't pull so I had to get something
out the door... Hence, some of my attitude about engineers. I've been let
down by engineering as a manager more often than I have been let down
by management as an engineer. And I've worked for some TERRIBLE CEOs.

This is an intellectually stimulating discussion for us, I'm sure, but basically
it's going to go around in circles for ever. Because software and the pressures
on the software industry are complex and interdependent. You literally cannot
point at one spot and say "THERE'S THE PROBLEM!" - if it was that easy,
don't you think it would have been fixed a long time ago??  In fact, in order to
have significant improvement in software quality (and therefore security)

EVERY ASPECT OF THE PROBLEM MUST BE ADDRESSED AT ONCE. If
you fix all of the problems below but one you've still accomplished nothing:
- We need to change how execs manage software companies
- We need to change customer's purchasing patterns
- We need to change how software middle managers manage software projects
- We need to change engineering practices and get engineers to write better code
        and do it faster
- We need to change how software is marketed (as long as it's cost-effective
        to just call your product Secure-* rather than make it secure, then that's
        what'll happen...)

Walking on water would probably be easier.

mjr.  
---
Marcus J. Ranum                         http://www.ranum.com
Computer and Communications Security    mjr () ranum com

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards