Malware "best practices"

[Ted Roche]

On Jul 27, 2006, at 7:11 PM, Jason Stephenson wrote:

> As a programmer, I can tell you why. Most programmers are not well  
> versed in the art or the science (if there really is any) of  
> programming.

There is a pretty large body of "Computer Science." Witness the ACM's  
Library or CS programs at MIT, Berkeley or CMU. However, we have an  
industry that needs 5% scientists and 95% practitioners at levels  
from architect through designer, planner, manager, tester and coder.  
Everyone on the assembly line at GM doesn't need a PhD in "Automotive  
Science" but they need well-designed tools and to follow a grand  
scheme they may only see a little piece of.

> Do you know why? Most programmers don't really get to see that much  
> source code. It's true. In the commercial realm of closed source  
> software most programmers only get to see the code of the project 
> (s) to which they are assigned. They never get to see much code  
> that's better or worse than what they are used to seeing.

True.

> The same is true in most university CS programs. Students are not  
> exposed to all that much code. It's mostly theory and mathematics  
> and then applying that theory and mathematics in code.

The "back page" opinion piece in last month's Communications of the  
ACM voices this same thought - stop having students write "toy"  
projects.

> Additionally, software is in its infancy. I imagine that the first  
> few thousand bridges that were built were pretty dodgy things. They  
> were probably very likely to collapse under you. It took mankind a  
> long time to figure all this out. (They still don't always do it  
> right as the big dig mess is proving.) Software is a bit more  
> complicated on the inside than making a bridge, too.

"One of the biggest reasons bridges come in on-time, on-budget and do  
not fall down is because of the extreme detail of design. The design  
is frozen and the contractor has little flexibility in changing the  
specifications. However, in today's fast moving business environment,  
a frozen design does not accommodate changes in the business  
practices. Therefore a more flexible model must be used. This could  
be and has been used as a rationale for development failure."

"But there is another difference between software failures and bridge  
failures, beside 3,000 years of experience. When a bridge falls down,  
it is investigated and a report is written on the cause of the  
failure. This is not so in the computer industry where failures are  
covered up, ignored, and/or rationalized. As a result, we keep making  
the same mistakes over and over again. "

The CHAOS Report, Standish Group, 1994
http://www.standishgroup.com/sample_research/chaos_1994_1.php

> Writing software is like writing fiction or nonfiction in the sense  
> that the only way to really get better is to do it. You read a lot  
> and you write a lot.--It helps to eat your own dog food, too.

In "Why Does Software Cost So Much?," DeMarco argues that the  
construction metaphor is a terrible choice, for many reasons like the  
arguments above. He has some great suggestions for some other  
metaphors to try.

Software development may have bases in science, but it is not yet an  
engineering discipline. That may take quite some time or, indeed,  
prove not to be an appropriate model.

Ted Roche
Ted Roche & Associates, LLC
http://www.tedroche.com