Food for Thought-An e-newsletter published by Software Quality Consulting, Inc.
May 2007, Vol. 4 No. 5
Learn from your Elders 

To view a web version of this newsletter, click on the following link:
http://www.swqual.com/newsletter/vol4/no5/vol4no5.html.

What topics would you like to see in this newsletter?  Each month, this
newsletter tries to provide you with useful information.  This is a two-way
street and your feedback is important.  Please send your thoughts and comments
to [email protected].

--------------------------------------------------------------------------------

Welcome to Food for Thought(TM), an e-newsletter from Software Quality
Consulting (http://www.swqual.com/index.html?Intro). I've created free
subscriptions for my valued business contacts. If you find this newsletter
informative, I encourage you to continue reading. Feel free to pass this
newsletter along to colleagues by clicking this Forward Email link
(http://ui.constantcontact.com/roving/sa/fp.jsp?plat=i&p=f&m=sctz69n6). If
you�ve received this newsletter from a colleague and would like to subscribe,
please click this Enter New Subscription link (http://www.swqual.com/newsletter/
Subscribe.htm?Newsletter). If you don't wish to receive this newsletter, click
the SafeUnSubscribe(TM) link at the bottom of this newsletter, and you won�t be
bothered again.

Your continued feedback on this newsletter is most welcome. Please send your
comments and suggestions to [email protected].

--------------------------------------------------------------------------------

*** In This Issue ***

In This Months� Topic, I offer some suggestions on selecting an 
appropriate development methodology...

Regular features to look for each month are:

- Monthly Morsels
  Hints, tips, techniques and reference info related to this month�s topic 

- Calendar
  Conferences, workshops, and meetings of interest to software engineers, 
  QA engineers and anyone interested in software development 

--------------------------------------------------------------------------------   

*** This Month�s Topic ***

Learn from your Elders 

At a recent Boston SPIN meeting (http://www.boston-spin.org/), I had a one-on-
one conversation with Ed Yourdon (http://www.yourdon.com/). 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 (http://www.yourdon.com/
publications/index.html) 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
(http://www.swqual.com/newsletter/vol2/no11/vol2no11.html)...

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 (http://www.swqual.com/newsletter/
vol3/no8/vol3no8.html), 

  �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 (http://www.ieee.org/
organizations/rab/gold/mentoring.html) 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... 

--------------------------------------------------------------------------------

*** Monthly Morsels ***

Every month in this space you�ll find additional information related to 
this month�s topic.

- References:

  [1] Excerpts from an e-mail from Ed Yourdon to Al Davis, February 2002. 

  [2] McConnell, S. and Tripp, L., �Professional Software Engineering � 
  Fact or Fiction�, IEEE Software, Nov/Dec 1999. (http://www.swqual.com/
  newsletter/vol3/no8/McConnell.pdf)

  [3] Humphrey, W., �The Quality Attitude�, news@sei newsletter, Number 3, 
  2004. (http://www.sei.cmu.edu/news-at-sei/columns/watts_new/2004/3/
  watts-new-2004-3.htm)

  [4] Humphrey, W., Winning with Software � An Executive Strategy, 
  Addison-Wesley, 2001. 

--------------------------------------------------------------------------------

*** Calendar ***

Every month you�ll find news here about local and national events that 
are of interest to the software community...

- Software Quality Calendar 

  There are many organizations that sponsor monthly meetings, workshops, 
  and conferences of interest to software professionals. Find out what�s 
  happening...
  (http://www.swqual.com/links/upcoming.html)

- Workshops Offered by Software Quality Consulting 

  Software Quality Consulting offers workshops in many topics related to 
  software process improvement. Get more info...
  (http://www.swqual.com/seminars/courses.html)

--------------------------------------------------------------------------------

*** About SQC ***

Software Quality Consulting provides consulting, training, and auditing 
services tailored to meet the specific needs of clients. We help clients 
fine-tune their software development processes and improve the quality of 
their software products. The overall goal is to help clients achieve 
Predictable Software Development(TM) � so that organizations can consistently 
deliver quality software with promised features in the promised timeframe. 

To learn more about how we can help your organization, visit our web site
(http://www.swqual.com/index.html?AboutSQC) or send us an email
([email protected]).

--------------------------------------------------------------------------------

I hope this newsletter has been informative and helpful. Your comments and 
feedback are most welcome. Send me your feedback ([email protected])...

Thanks,

Steve Rakitin
[email protected]


Food for Thought, Predictable Software Development, Act Like a Customer,
and ALAC are trademarks of Software Quality Consulting, Inc.
Copyright 2007. Software Quality Consulting, Inc. All rights reserved.
Graphic design by Sage Studio