Learn from your Elders

At a recent Boston SPIN meeting, I had a one-on-one conversation with Ed Yourdon. Ed is truly a visionary in our field. After graduating from MIT, he started working in the computer industry in 1964 at Digital Equipment Corporation where he wrote the FORTRAN math library for the PDP-5 and the assembler for the popular PDP-8 minicomputer. He has since written 27 books and become a world renowned consultant on software engineering methodologies and web technology.

I asked Ed why it seems that younger software engineers aren’t learning critical project management skills from their more experienced colleagues. He agreed that this seems to be the case and recalled a conversation he had with a colleague on this subject. After the meeting, I sent Ed an e-mail asking him about this conversation and he replied by sharing the e-mail with me. This is what he wrote:

“Prior to the 1960s, we lived in what anthropologist Margaret Mead referred to as a ‘post-figurative’ world, in which society and technology was relatively stable from one generation to the next; that was obviously true to an even greater extent in the 19th century, and even more so in the 18th century.  The result of that situation is that each generation learned how to function in society reasonably successfully, and since things were more-or-less the same when THEIR kids began growing up, it was “obvious” that parents knew more than kids, and that kids could (and should) learn whatever they needed to know from their parents. There was still the phenomenon of puberty-based rebellion, and the need to go explore uncharted frontiers that the older generation hadn’t gotten to yet; but the general perception was that parents knew what they were talking about, and kids went through an apprenticeship period in order to acquire that knowledge and experience.

By the 1960s, though, we had entered a ‘co-figurative’ state, according to Margaret Mead; technology, society and politics were changing so quickly that parents and children were faced with dramatically new and different circumstances at the same time, and thus both had to learn new skills and new behaviors at the same time.

The most extreme form of this process is a ‘pre-figurative’ state, in which technology is changing so quickly that old timers can’t keep up with it, and children learn BEFORE their parents.  A trivial example we’ve all seen is the parent who is so befuddled by the task of programming a VCR that he simply gives up and asks his 8 year old kid to do it.”  [1]

According to Ed, each new generation of software engineers believes that the previous generation is “old-fashioned” and “just doesn’t get it”. These kids were raised in the technology era and believe that technology and technology alone can solve all problems. While they are definitely able to assimilate change and new technology faster than the previous generation and certainly faster than the Baby Boomers, what they don’t get is:

“As the older generation gets older and older, and as it accumulates more and more scars from years of project experiences, it realizes that politics and people represent 99.9% of the difference between success and failure.” [1]

The current generation of software developers has much to learn about effective project management techniques. In fact, the approach most often used to develop software today is often referred to as the “code-and-fix” approach. As Steve McConnell observed:

“The most common approach to software development today is code-and-fix programming – or hacking. In this approach, a development team begins with a general idea of what they want to build. They might have a formal specification, but probably not. They use whatever combination of informal design, code, debug, and test methodologies suits them. Programmers write a little code and run it to see whether it works. If it doesn’t work, they change it until it does.

The code-and-fix approach is far from the state of the art in software development. It costs more, takes longer, and produces lower-quality software than other approaches; its main advantage is that it requires little technical or managerial training. Leading organizations have known and used effective software development practices for decades, but the gap between average practice and best practice in software is enormous.” [2]

The “code-and-fix” approach represents one end of the product development spectrum. At the other end is the “get-it-right-the-first-time” approach. Watts Humphrey [4] stated that this approach is always the most efficient way to work.

However, we often need to find a middle-ground since we don’t always have all the requirements and as a result, we have to do some amount of code-and-fix.

The issue here is that when we use the code-and-fix approach, the likelihood that we inject more defects increases significantly. We need effective techniques to mitigate this problem…

Desk-check your work!

Desk-checking your work is like proof-reading a report or other document. Sure, word processors can find spelling errors and some grammatical gaffes but spell checkers have limitations. The following sentence draws no complaints from most spell checkers:

Eye oft ten remand stew dents that spill-chick cant reed fur scent.  Ass any one who reeds this can sea, spill-chick is not gong to ketch awl mist takes.  It’s no subs tee toot fir poof reeling.

Compilers, like spell checkers, are good at finding common syntax errors. But compilers often can’t find subtle semantic errors, such as misplaced semi-colons or missing else clauses. In addition, compilers are software, and as we all should know by now, all software is defective…

Young software engineers don’t seem to have learned why desk-checking their code before compiling is so important. The attitude of younger software engineers seems to be:

“Why spend time desk checking my code when I can let the compiler find most of my mistakes…”

Allowing the compiler to find your mistakes means that you are not taking responsibility for the defects you have created, as Watts Humphrey observed:

“The current common view that it is impossible to produce defect- free software is an excuse for not making the effort to do quality work. To do quality work, developers need to:

• Insist on starting with clearly written requirements
  
• Perform peer reviews of requirements, designs, code
  
• Apply conceptual integrity to system design
  
• Take pride in your work!” [3]

So, even when we are forced to use a code-and-fix approach, there are ways we can take responsibility for the quality of our work and minimize defects injected…

Desk-checking is a technique that SQA engineers can benefit form as well. Desk-checking tests is a good way to save time by making sure the test is correct before trying it out.

You can learn from your elders

As a young software engineer, I was fortunate to have had the opportunity to learn from several skilled and talented engineers during my “apprenticeship”. These mentors not only helped me with technical skills but also helped me with:

• Inter-personal communication skills
• Writing and presentation skills
• Management skills
• Understanding corporate culture and politics

They also taught me how to use “the system” to get work done. These skills are not taught in school and cannot be supplanted by the latest technology.

As I stated in my Oct 2006 newsletter,

“The natural hierarchy that exists in other engineering professions does not exist in the software engineering profession. Software engineering lacks apprentice and mentoring relationships common in most every engineering profession. Such relationships are critical if software engineering is ever to become a true engineering profession.”

When I asked Ed why he thought young engineers are not learning from their more experienced peers, he observed that:

“The problem is that they tended to ignore and reject ALL of our lessons, including those that were language-independent and that could be (and should be) re-expressed in whatever modern terminology is appropriate.  Ultimately this does happen, and the new generation is dazzled by terminology like ‘use cases’, when the older generation shakes its head in amusement and thinks back to the equivalent notion of data-flow diagrams. But even more important, the younger generation tends to think that ALL problems are technologically-oriented, and that they can all be solved by brute-force application of a newer, better, faster, cheaper technology. They don’t like politics, don’t communicate or socialize well, and thus tend to shy away from those areas.  

Sometimes the technology is the straw that breaks the camel’s back, but most of the time there are far more fundamental issues and problems that need to be solved; and these are the same issues and problems that I faced when I stumbled into the computer field in 1964, and are probably the same as every engineering-oriented project faced all the way back to the days of the building of the pyramids.” [1]

Everyone Needs a Mentor

Since the software engineering profession doesn’t recognize the importance of an apprenticeship, it is imperative that young software engineers and SQA engineers find a mentor. Mentors can provide young engineers with essential “soft” skills that can help them improve their effectiveness and provide them with skills that can only be handed down from a more experienced engineer.

Some organizations have recognized the importance of mentoring young engineers and have in-house mentoring programs. If your company is one of these organizations, participating as either a mentor or mentee can provide significant benefits to both the organization and to the individuals involved.

If your organization does not have an in-house mentoring program, the IEEE can help. Recently, the IEEE launched a mentor program which aims to identify IEEE members who are looking for mentors and pair them with IEEE members who are interested in being a mentor.

‘Till next time…