Safer String Implementation

I came across this 'safer' string implementation and had to ask, "How is this 'safer'?"

struct safe_string
{
    safe_string(const std::string & str = std::string())
        : str_ (str.c_str())
    {
    }

    safe_string(const safe_string & copy)
        : str_(copy.str_.c_str())
    {
    }

    safe_string & operator = (const safe_string & copy)
    {
        str_ = copy.str_.c_str();
        return *this;
    }

    std::string           str_;

};

Recovery System - failure

Many years ago I was working with a team of developers trying to determine why their recovery system was not properly reading the recovery data files. We discovered that the so called recovery system was reading the recovery file correctly on startup, however the code snippet below was identified by PC-Lint as being the most likely candidate for our recovery problems, but this code never wrote any warnings to the syslog.

// functionality removed for clarity
// this 'logic' will always fail to write 'iSize' bytes of data
// why?
void write_data(void* pData, size_t iSize)
{
    int fd = 0;
    // 
    // open file for writing and set 'fd'
    //
    size_t dwOffset = 0;
    if( (_lseek(fd, static_cast(dwOffset), SEEK_SET) < 0) ||
        (_write(fd, pData, static_cast(iSize) < 0) ) )
    {
        // we get here if _lseek returns an error (e.g. -1)
        // or if we fail to write 'iSize' bytes of 'pData' to a file
    }
}

When we ran PC-Lint on the above source code we found the following warnings:

Warning 685: Relational operator '<' always evaluates to 'false'
Warning 568: non-negative quantity is never less than zero

Why don't more developers and/or software companies use PC-Lint? It should be standard practice to remove warning and errors from source code before building, testing and releasing, yet it has been our experience that few companies use static analysis before running unit tests and before releasing builds.

when exporting C++ (template) objects is *not* a good idea

Most of the time, compilers are your enemies because they will do almost anything they can to compile your warm steaming pile of code into a binary image. Clearly the author of this code was having troubles and thought it best to warn others of his insanity. Apparently the correct solution of never export C++ objects out of a DLL was not an option?

// We disable this warning (4251) for the entire project because
// our code is exporting objects that contain stl templates.
// It seems to be the general idea on the internet to simply disable this warning
// since it is hard to eliminate it.

#pragma warning( disable : 4251)

induced current

http://www.xkcd.com/509

The next big network threat - Generation Y

A recent Information Week article describes why those individuals who can't remember the Bee Gees are the next network threat to enter the corporate world.  That's right it's the Gen Y employees who pose the newest and greatest risk to network security.  Here are the top reasons Gen Y pose a security risk.

Since Nov. 5, three separate studies -- from Accenture, Intel, and ISACA, a major IT users group -- have indicted the youngest generation of employees as one of the enterprise's newest and most serious security risks. People under the age of 28 -- sometimes called Generation Y and sometimes called Millenials, depending on how you define the category -- are engaging in online behavior that could expose their organizations to data leakage and information theft, the studies say.

In a study published Nov. 13, Intel and the research firm of Penn Schoen & Berland Associates offered similar conclusions.  About half of the respondents regard Generation Y as a serious security concern, according to the study.

Younger employees' propensity to download non-sanctioned applications and social media tools was one of the chief reasons cited for IT professionals' concern. Risks posed by social networking sites such as Facebook and MySpace were the most frequently mentioned, according to the study.

This survey clearly shows that younger employees are more likely to engage in online activities at work that put a business' IT infrastructure at risk," said Kent Anderson, a member of ISACA's Security Management Committee. "The fact that [they] are planning to spend the equivalent of more than half a work day doing holiday shopping from their work computer, combined with their lack of concern for how secure their computer is, points to an urgent need for employee education.

Who is the worst programmer on the team?

Ester Shindler asked a question on LinkedIn the other day and summarized in an article for CIO Magazine.  She asked, 

"Who's the worst programmer on your team? How can you tell?"

We all can point a finger at the one person in our group who should be let go, we all know which code generating wildebeest should be eaten by the pack of lions nipping at our binary heals.  But what metrics are we using?  Here's the list from a recent CIO article:

• Don't care about the quality of work
  
• Cost the team in time and frustration
  
• Have a poor sense of timeliness
  
• Don't offer nor ask for help
  
• They ask the wrong questions
  

/dev/kde

Looking into the software mirror

Fred Brooks observed that "software tends to resemble the organization that built it".  I think we can take this one step further, "software tends to resemble the individual that built it."

I have had the pleasure of working for a number of companies and refactored countless lines of code (usually C, C++ and FORTRAN) and as a friend likes to say "I've written an awful lot of code and a lot of awful code".

The vast majority of the code I've inherited leads me to believe that many programmers lack a fundamental understanding of software development; lack an understanding of the basics of the language in which they are programming; lack the knowledge to write constructors, destructors and in general lack an understanding of resource management.  I am truly shocked to see how many programmer lack the basics of "is-a" and "has-a"; lack debugging skills; lack an even basic understanding of how to write a function interface and pay no attention at all to return values.

I've also come to understand that managers I've worked for rely on me to fix many of the corporate shortcomings with a mantra of "if it doesn't work" give it to that curmudgeon in the cubical down the hall because he can fix it".  I am the first to admit I am not a code guru, I am not a Bjarne, nor a Linus.  I come to the office each day with a blue collar, lunch box mentality to create profitable software.  I'm not out to save the world, nor create a software masterpiece.  I realize that at the end of the day, at the end of the build process, our software will be running in a data center manned by intelligent men and women who, mostly have two year tech degrees and have hundreds of servers to monitor, upgrade and respond to outages.  So I create software that starts and stops w/o errors and runs with triple digit uptimes.

Is the sad state of programming because universities are failing, or because those who attended universities are failing to put in the time and effort to (re)learn?  So what is the current state of programming?  In light of the multi-core revolution taking place, I fear for the future of the craft.  If single-threaded programming confuse programmers, what will multi-core techniques do to our work environment?

/dev/kde