Dr. Dobb's | Quick-Kill Project Management | June 30, 2006

[Kevin.Wall at qwest.com (Wall, Kevin)]

Kenneth Van Wyk writes...

> http://www.ddj.com/dept/architect/189401902
> ...
> Put another way, how does a team hold  onto its good practices (not
> just security reviews) when they're in crisis mode?  I'm sure that
> the answer varies a lot by team,  priorities, etc., but I'd welcome
> any comments, opinions, etc. from  any of you who have been in
> similar situations.

I've been in this situation several times in my 25+ years in software
development (especially with post-divestiture Bell Labs). During the
times that it has been successfully addressed, I've noticed one major
common theme and that is that the development team (and particularly the
team lead) has got to have the "balls" to stand up to management and
tell
them that the dev team is unwilling to compromise on quality / security
/
(fill-in-the-blank-with-whatever-is-important-to-you) and that the
ONLY way that it can be done is to drop certain FUNCTIONALITY
(which usually management is reluctant to do).

How successful this approach is depends on the several things
(not a comprehensive list):

        1) Whether the team has any credibility with management or not.
       (Hint: If you've already slipped your original schedule several
       times, you probably don't have any. :-)
        2) How well the dev team presents its arguments, especially in
       terms of risks of NOT doing testing / security reviews /
       insert-your-favorite-here. (Since security is in a large part
       about _managing_ risks, this fits in nicely.) You need to
remember
       though that ultimately, it is management's discretion whether or
       not to accept the risk(s), not the development team's.
        3) How tactfully you present your case. (I.e., don't be
arrogant; be
       willing to show some flexibility, e.g., working some additional
       hrs of unpaid OT; etc.)
    4) Know your Brooks' _Mythical Man-Month. Management almost
certainly
       will offer to give you more developers/testers/etc. This is
almost
       always a bad ROI since you will spend more time bringing those
       individuals up-to-speed on your project than you will get back
       in productivity. Also, know your Capers Jones'; he has produced
some
       excellent documentation that shows that dropping things like
software
       code inspections actually increases software costs and
       time-to-delivery.

It also greatly helps to have a team with enough spine that they all are
willing to walk and find another job if they feel that they are being
held hostage and being forced to make unnecessary compromises.

I have been fortunate to have worked with many such teams in the past
who consider their craftsmanship and pride in their work more important
than prevalent "finish this yesterday" mentality, including a few
teams that HAVE been willing to walk out in such situations. (Of course,
that was during the dotcom boom, when all you had to do to find an
development job was to know how to spell "www". I'm not sure how
committed
those people would have been during the leaner times.)

BTW, I am proud to say that the application security team that I have
worked with for the past six years or so have had the courage to insist
that best practices such as formal use cases, design reviews, code
inspections, etc. be followed even though the _formal_ IT process had
thrown such practices out the window in favor of so-called XP
development
practices. (When it comes to security, I tell management that XP stands
for "eXpect Problems" rather than "eXtreme Programming".)

Of course, it is best to avoid situation like those described in the
_Dr. Dobb's_ article in the first place. That's where it's useful to
have a skill in estimating development effort, and one unfortunately
where I think we as an industry have a rather poor track record.

But that's another topic entirely.

-kevin
---
Kevin W. Wall           Qwest Information Technology, Inc.
Kevin.Wall at qwest.com Phone: 614.215.4788
"The reason you have people breaking into your software all 
over the place is because your software sucks..."
 -- Former whitehouse cybersecurity advisor, Richard Clarke,
    at eWeek Security Summit
> I saw an article on Dr. Dobb's (via Slashdot) this morning that made  
> me pause a bit.  The article is on "Quick-Kill Project 
> Management" --  
> full link is here:
>
> http://www.ddj.com/dept/architect/189401902
>
> The article describes a small project team (say 5 developers) who  
> have suddenly had their dev schedule drastically accelerated on them  
> by powers outside of their control.  It describes some techniques  
> that the dev leader can use to concentrate the team's focus on  
> killing (hence the name) the most pressing of issues.  Not  
> surprisingly, there's no mention of security in the article, 
> although  
> they do talk about conducting code reviews, but only for functional  
> defects in the code.
>
> What caught my attention here is that I'll bet that a *lot* of small  
> dev teams end up in situations very similar to the one described in  
> the article's opening statements.  In that sort of situation (where  
> the company VP says "finish this yesterday"), I'd expect that doing  
> just about any sort of security review is the first thing to be  
> dropped from the dev schedule.  I wonder, though, if teams that have  
> already integrated (say) static analysis tools into their 
> build cycle  
> might have a fighting chance at *not* dropping those checks during  
> this kind of "death march".  Put another way, how does a team hold  
> onto its good practices (not just security reviews) when they're in  
> crisis mode?  I'm sure that the answer varies a lot by team,  
> priorities, etc., but I'd welcome any comments, opinions, etc. from  
> any of you who have been in similar situations.
>
> Cheers,
>
> Ken
>
> Kenneth Van Wyk
> KRvW Associates, LLC
> http://www.KRvW.com


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.