|
Server : Apache/2.4.62 System : FreeBSD fbsdweb2.web.rcn.net 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 User : www ( 80) PHP Version : 8.3.8 Disable Function : NONE Directory : /domains/srakitin/OLD/newsletter/vol3/no7/ |
Upload File : |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Food for Thought: Are We There Yet?</title>
<link href="/newsletter/StyleSheet.css" rel="stylesheet" type="text/css">
</head>
<OpenTracking/>
<!-- Do NOT delete previous line if you want to get statistics on the number of opened emails -->
<body>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0">
<tr align="center" valign="top">
<td colspan="2"><img src="/newsletter/images/FoodForThoughtLogo.gif" width="600" height="105"></td>
</tr>
<tr class="Reference">
<td align="left" valign="top"><p>An e-newsletter published by<br>
Software Quality Consulting, Inc. </p>
</td>
<td align="right" valign="top"><p>September 2006, Vol. 3 No. 7 <br>
[<a href="/newsletter/vol3/no7/vol3no7.txt" target="_blank">Text-only Version</a>] </p>
</td>
</tr>
</table>
<br>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td align="left" valign="top"> <p> Welcome to <em><strong>Food for Thought™</strong></em>, an e-newsletter from <strong> <a href="/index.html?Intro" target="_blank">Software Quality Consulting</a></strong>. 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 <strong><a href="http://ui.constantcontact.com/roving/sa/fp.jsp?plat=i&p=f&m=sctz69n6">Forward Email</a></strong> link. If you’ve received this newsletter from a colleague and would like to subscribe, please click this <strong> <a href="/newsletter/Subscribe.htm?Newsletter" target="_blank">Enter New Subscription </a></strong>link. If you don't wish to receive this newsletter, click the <strong><a href="#bottom">SafeUnSubscribe</a></strong>™ link at the bottom of this newsletter, and you won’t be bothered again.</p>
<p>Your continued feedback on this newsletter is most welcome. Please send your comments and suggestions to <strong><a href="mailto:[email protected]">[email protected]</a></strong>.</p></td>
</tr>
</table>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="right" valign="top" background="/newsletter/images/RedSpacer.gif"><div align="center"><img src="/newsletter/images/InThisIssue.gif" width="114" height="37"><br>
</div></td>
<td width="15"> </td>
<td align="left" valign="top"><p> In <a href="#article"><strong>This Months’ Topic</strong></a>,
<FONT face=Verdana size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">I discuss the evolution of the software engineering discipline…</SPAN></FONT><br>
<br>
Regular features to look for each month are:</p>
<ul>
<li> <a href="#morsel"><strong>Monthly Morsels</strong></a><br>
Hints, tips, techniques and reference info related to this month’s topic</li>
</ul>
<ul>
<li> <a href="#calendar"><strong>Calendar</strong></a><br>
Conferences, workshops, and meetings of interest to software engineers, QA engineers and anyone interested in software development</li>
</ul>
</td>
</tr>
</table>
<br>
<br>
<a name="article"></a>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="left" valign="top" background="/newsletter/images/RedSpacer.gif"><p align="center"><img src="/newsletter/images/ThisMonthsTopic.gif" width="114" height="37"><br>
</td>
<td width="15"> </td>
<td width="471" align="left" valign="top" class="BodyText"><p align="center" class="Headline">Are We There Yet?</p>
<p> Every parent has heard this question a million times. When my kids were little, I would hear this question as we were backing out of the driveway. “No, not yet.” I would reply…</p>
<p> I have thought about this question with regard to software engineering. The software engineering discipline has experienced major changes since the late 1950’s. In contrast, changes to more mature engineering disciplines have been much more subtle. The journey has been anything but smooth – there have been many bumps along the road. To understand where software engineering is heading, we need to first understand from whence it came…</p>
<p><strong> When did it become software engineering?</strong></p>
<p> The term <em>software engineering</em> was was first used in the late 1950s. However, it wasn’t until 1968 at a NATO Science Committee conference that software engineering was recognized as an emerging engineering discipline.</p>
<blockquote>
<p> An interesting historical footnote - During the 1950’s and 60’s the job of programming computers was performed mostly by women. Many women mathematicians, led by <strong><a href="http://ei.cs.vt.edu/~history/Hopper.Danis.html" target="_blank">Admiral Grace Hopper</a></strong>, were instrumental in proving that computers could be used to solve real-world problems. During this same time, men were primarily focused on hardware engineering – which was then considered to be a more prestigious job...</p>
</blockquote> <p> Universities initially offered computer programming courses through the Mathematics or Physics Departments. This is partly a result of early computer users – who were primarily mathematicians and physicists. It wasn’t until the 1980’s that universities established departments and curricula specific to Computer Science at the undergraduate level.</p>
<p> Back in the day, developing programs involved using what now seems like stone age tools such as pencil and paper, flow chart templates, and coding sheets. Programs were “designed” by drawing detailed flowcharts. Programs were “written” by typing statements on computer punch cards using a keypunch machine.</p>
<table cellpadding="15" cellspacing="0" class="BodyText">
<tr align="center" valign="top">
<td width="50%"><p align="center"><img width="177" height="125" src="/newsletter/vol3/no7/vol3no7_clip_image002.jpg"></p>
</td>
<td width="50%"><p align="center"><img width="178" height="167" src="/newsletter/vol3/no7/vol3no7_clip_image004.jpg"></p>
</td>
</tr>
<tr align="center" valign="top">
<td>Flowchart Templates</td>
<td>IBM Coding Sheets</td>
</tr>
<tr align="center" valign="top">
<td width="50%"><p align="center"><img width="186" height="140" src="/newsletter/vol3/no7/vol3no7_clip_image006.jpg"><br>
</p>
</td>
<td width="242" colspan="2"><p align="center"><img width="157" height="161" src="/newsletter/vol3/no7/vol3no7_clip_image008.jpg"></p>
</td>
</tr>
<tr align="center" valign="top">
<td>Computer punch cards</td>
<td colspan="2">IBM Keypunch Machine</td>
</tr>
</table>
<p>After spending countless hours at the keypunch machine, the “card deck” was submitted to the computing center. Large mainframes were often hidden from view behind smoke-colored windows - accessible only to the first generation of computer nerds. Card readers would read your card deck along with dozens of others. Often, the card readers would mangle your cards and the computer operator occasionally got card decks mixed up. This required more hours of re-punching and re-ordering of your card deck. Once your card deck was successfully read, the first pass would often result in many compiler errors. After several iterations (which could take hours or even days), the program would finally compile cleanly. Only then would it be possible to begin the task of determining if it worked properly…</p>
<p><strong> The Emerging Software Crisis</strong></p>
<p> <FONT face=Verdana size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">During the 1980’s</SPAN></FONT>, “programming” began its evolution into “software engineering”. But the fledgling software industry was facing its first significant challenge. By the end of the 1980’s, companies were spending more money on software maintenance activities than they were on new development. Quality was abysmal. Productivity was low. This was the infamous “software crisis” of the 1980’s – the first significant bump in the road. High profile software failures started appearing in the news. These failures resulted in economic losses and in a few cases, <strong><a href="/newsletter/vol2/no10/Therac-25.pdf" target="_blank">loss of life</a></strong><a href="/newsletter/vol2/no10/Therac-25.pdf" target="_blank"></a>.</p>
<p> The “software crisis” gave rise to the <strong><a href="/newsletter/vol3/no7/MethodologyWars.pdf" target="_blank">Methodology Wars</a></strong>. Software gurus of the day advocated their own software development paradigms that were sure to get us out of this mess – what Fred Brooks called the <strong><a href="/newsletter/vol3/no7/No%20Silver%20Bullett%20Essence%20and%20Accidents%20of%20Software%20Engineering%20Fred%20Brooks%20IEEE%20Computer%20April%201987.pdf" target="_blank">Silver Bullet</a></strong>. They all promised, “if only those lazy, good-for-nothing programmers would adopt <em>their</em> methodology, all of our problems would be solved!” Ed Yourdon, James Martin, Tom DeMarco, and many others published their own methodologies and established cult-like followings.</p>
<p> Hindsight has shown that none of these methodologies ever lived up to their hype.</p>
<blockquote>
<p> Another interesting historical footnote: The object-oriented methodology evolved from many sources including <strong><a href="http://en.wikipedia.org/wiki/Smalltalk" target="_blank">smalltalk</a></strong>, <strong><a href="http://en.wikipedia.org/wiki/Simula" target="_blank">Simula 67</a></strong>, and <strong><a href="http://en.wikipedia.org/wiki/Modula-2" target="_blank">Modula</a></strong>. As O-O methods started to become popular, many developers learned O-O programming languages like C++ before learning O-O Analysis and Design techniques. As a result, many early C++ programs thought to be “object-oriented” really were not because the developers had not learned to think differently. <strong> </strong></p>
</blockquote> <p><strong> Chief Programmer Teams</strong></p>
<p> In the 1970’s when Harlan Mills created the first Chief Programmer Team [4], he acknowledged a fact of human nature:</p>
<blockquote>
<p> all programmers are not created equal – some are more adept than others at specific tasks such as architecture, design, coding, or testing…</p>
</blockquote>
<p> (Do you see the similarity between <strong><a href="http://www.firstmonday.org/issues/special10_10/koch/index.html" target="_blank">Chief Programmer Teams and current Agile Methods</a></strong>?)<br>
<br>
</p>
</td>
</tr>
<tr>
<td align="left" valign="top" background="/newsletter/images/RedSpacer.gif"><p><img width="110" height="83" src="/newsletter/vol3/no7/Urinals.jpg"></p>
<p align="center"> <span class="Reference">What can<br>
happen when conceptual<br>
integrity</span> <span class="Reference">is<br>
ignored… </span></p>
<p> </p></td>
<td> </td>
<td align="left" valign="top" class="BodyText"><p>Another important contribution from Chief Programmer Teams was the notion of <strong><a href="http://en.wikipedia.org/wiki/The_Mythical_Man-Month" target="_blank">conceptual integrity</a></strong>. According to Fred Brooks:</p>
<blockquote>
<p> “I will contend that conceptual integrity is <em>the</em> most important consideration in system design. It is better to have a system omit anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.” [2]</p>
</blockquote>
<p> During the 1980’s some people believed that the <strong>Silver Bullet</strong> could be found in better tools. <strong><a href="http://en.wikipedia.org/wiki/Computer-aided_software_engineering" target="_blank">CASE Tool</a></strong> companies developed and marketed all sorts of tools that promised significant improvements in productivity and quality. Not surprisingly, many of these tools never lived up to their hype either.</p>
<p> Others believed that more process was the solution. This eventually led to the establishment of the <strong><a href="http://www.sei.cmu.edu/" target="_blank">Software Engineering Institute (SEI)</a></strong> and the <strong><a href="http://www.sei.cmu.edu/cmm/cmm.html" target="_blank">Capability Maturity Model ® (CMM)</a></strong>– one of the heaviest of the heavyweight processes.</p>
<p> The CMM ® and CMMi ® have been widely used for large government development projects. Outside of this arena, they are criticized as being overly bureaucratic and inefficient. This criticism begat the evolution of lightweight processes, commonly referred to as <strong><a href="http://en.wikipedia.org/wiki/Agile_methods" target="_blank">Agile Methods</a></strong>.</p>
<p><strong> The Bubble</strong></p>
<p> During the 1990’s, the software engineering journey shifted into high gear. <FONT face=Verdana size=2><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">As Internet access spread across the globe</SPAN></FONT>, it created explosive growth in software development. <FONT face=Verdana size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">While software was being applied to more and more problems</SPAN></FONT> (as well as to things that were not problems), it also caused more and more problems. High profile <strong><a href="/newsletter/vol2/no10/vol2no10.html" target="_blank">software failures were becoming commonplace</a></strong><a href="/newsletter/vol2/no10/vol2no10.html" target="_blank"></a>.</p>
<p> The dot.com debacle of the late 1990’s negatively impacted the reputation of software engineering. As thousands of dot.com companies sprang up over night, they competed fiercely for a very limited number of experienced software engineers. Many dot.coms hired people to develop web applications who had little or no training in software engineering principles. As a result, many of these applications became major disasters…</p>
<p> The proliferation of software that was fueled by the Internet has created <strong><a href="/newsletter/vol3/no4/vol3no4.html" target="_blank">new problems</a></strong> for software engineers and new challenges for software engineering. Hackers, SPAM, virtual terrorists, security leaks, identity theft, etc. are just some of the problems that have resulted from the proliferation of software since 2000. </p>
<p><strong> So, are we there yet?</strong></p>
<p> The <strong>Methodology Wars</strong> that started in the 1980’s are still raging. Today, it’s lightweight vs. heavyweight processes, Agile vs. traditional methods. One thing we should have learned by now is that…</p>
<p align="center"><strong> There still is no silver bullet and there probably will never be…</strong></p>
<p> As Roger Pressman said:</p>
<blockquote>
<p> “I contend that software engineering principles <em>always </em>work. It’s never inappropriate to stress solid problem solving, good design, and thorough testing (not to mention the control of change, an emphasis on quality,...). A specific software process might fail because it is overkill, or the work products it requires are unnecessary or burdensome, or a person or team becomes overly dogmatic in the application of the process. But history is on the side of a solid engineering approach.” [1]</p>
</blockquote>
<p>I couldn’t agree more. If software engineering is ever to become a respected engineering discipline, it has to be based on sound engineering principles – principles that have been shown to work. So what are some examples of such principles? Most of us probably have many examples… </p>
<p><strong> Apply Sound Engineering Principles…</strong></p>
<p> There have been many outstanding software engineering books written in the past five decades. Of all the computer science and software engineering books that have been published in the past 50 years, only a few have published special anniversary editions – more than two decades after they first appeared. Why is that? It’s because their message still rings as true today as it did when they were first published. They embody many sound engineering principles…</p>
<p> What are these very special books?</p>
<blockquote>
<p><strong><a href="http://www.awprofessional.com/bookstore/product.asp?isbn=0201835959&rl=1" target="_blank">The Mythical Man-Month, by Fred Brooks</a> [2]</strong></p>
<p> A few examples of the lessons described by Brooks that he observed more than 30 years ago and still apply today include:</p>
<p><strong> Adding staff to a late project will only make it later.</strong></p>
<p> <FONT face=Verdana size=2><SPAN
style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana">Hard to believe that there are managers out there that still don’t get this…</SPAN></FONT></p>
<p><strong> Conceptual Integrity </strong></p>
<p> This is probability the most important aspect of designing systems that isn’t taught in colleges and universities. When I meet with young software engineers, I often ask them about this and usually get a puzzled look.</p>
<p><strong> Plan to throw one away </strong></p>
<p> As the complexity of software has increased and the number of new systems grows, companies need to recognize that product marketing is not likely to get it right the first time. Planning to throw the first one away means you trash the code not the knowledge gained. And, we need to remember that the knowledge is far more valuable than the code.</p>
<p><strong> Learn to develop accurate project estimates and realistic schedules</strong></p>
<p> I can’t tell you how many times I’ve seen project teams give management the answer Management wants rather than the truth. Haven’t these people read <strong><a href="http://www.amazon.com/Death-March-Second-Edward-Yourdon/dp/013143635X/sr=1-1/qid=1158089440/ref=pd_bbs_1/103-2069278-6377461?ie=UTF8&s=books" target="_blank">Death March Projects</a></strong>? If you want to develop better estimates and realistic schedules, you need to first <strong><a href="/training/schedules.html" target="_blank">train people how to do this</a></strong>, and then, require that they do it. Managers, you need to be prepared for schedules that may not fit with your goals. The answer is to not force the schedule to fit, but rather, negotiate with the project team to see what can reasonably be done with the given resources and requirements…</p>
<p><strong> Communication </strong></p>
<p> Since software engineering is an inherently human process, communication between humans developing software is probably pretty important. Yet, software engineers are notoriously bad communicators. Ever read a good requirements spec? They are few and far between. Product marketers are just as bad at communicating as software engineers. The common thread – English – one of the worst languages there is for stating requirements for software. English is inherently vague and ambiguous. Software must be deterministic. Do you see why there are so many communication problems here? <strong><a href="/newsletter/vol3/no3/vol3no3.html" target="_blank">Read more…</a></strong></p>
</blockquote>
<p>The other special book is from Gerry Weinberg and addresses some key behavioral characteristics of developers. He observed these issues over 35 years ago and yes, they still apply today:</p>
<blockquote>
<p><strong><a href="http://www.dorsethouse.com/books/psy.html" target="_blank">The Psychology of Computer Programming, by Gerald Weinberg</a> [3]</strong></p>
<p> Weinberg identified several key personality traits that are critical for success as a software developer. These traits include:</p>
<ul>
<li> Ability to <strong>adapt to rapid change</strong></li>
</ul>
<ul>
<li><strong> Organizational skills</strong> and the ability to keep track of lots of important bits of information </li>
</ul>
<ul>
<li><strong> Humility</strong> – your code <strong>will</strong> have problems that <strong>will</strong> be found by others </li>
</ul>
<ul>
<li> Some level of <strong>assertiveness</strong> – needed to get things done often in the face of many obstacles </li>
</ul>
<ul>
<li><strong> A sense of humor</strong>, since the computer “doth make fools of us all”. </li>
</ul>
</blockquote>
<p>The take away message from these books is that software development is a complex human activity that is influenced by many factors. To be successful, its my contention that software engineering requires three critical ingredients:</p>
<p align="center"><img width="252" height="222" src="/newsletter/vol3/no7/vol3no7_clip_image010.jpg"><br>
<br>
</p></td>
</tr>
<tr>
<td align="left" valign="top" background="/newsletter/images/RedSpacer.gif" class="Reference"><p align="center"><strong> What topics<br>
would you<br>
</strong><strong>like to see<br>
discussed?</strong></p>
<p align="center">Each month,<br>
this newsletter<br>
tries to provide<br>
you with useful information.<br>
This is a<br>
two-way street<br>
and your<br>
feedback is important.<br>
Please send<br>
your thoughts<br>
and comments<br>
to<br>
<strong><a href="mailto:[email protected]">steve@<br>
swqual.com</a></strong> </p>
</td>
<td> </td>
<td align="left" valign="top" class="BodyText"><p>I’ve observed that many organizations have one of the three, a few have two of the three, and only best in class companies have all three.</p>
<p><strong> Summary</strong></p>
<p> Lewis Carroll said that<strong> if you don’t know where you are going, any road will get you there</strong>. Software engineering is still a relatively young engineering discipline. The journey has had its ups and downs. I don’t know where things will end up but being a passenger on this journey has enabled me to make some observations and draw some conclusions. I’m enjoying the trip but sometimes it seems like <strong><a href="http://www.firesigntheatre.com/albums/album.php?album=bozos" target="_blank">We’re All Bozos on This Bus</a></strong>.</p>
Until next time…</td>
</tr>
</table>
<br>
<br>
<a name="morsel"></a>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="right" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/images/MonthlyMorsels.gif" width="114" height="37"></td>
<td width="15"> </td>
<td align="left" valign="top"><p> Every month in this space you’ll find additional information related to this month’s topic.</p>
<ul>
<li><strong> References:<br>
<br>
</strong>[1] Pressman, R., “What A Tangled Web We Weave”, <em>IEEE Software</em>, Jan/Feb 2000, pp. 18-21.<br>
<br>
[2] Brooks, F., The Mythical Man-Month, Addison-Wesley, first published 1975. Silver Anniversary edition published 1995.<br>
<br>
[3] Weinberg, G., The Psychology of Computer Programming, Dorset-House, first published 1971, silver anniversary edition published 1998.<br>
<br>
[4] H. Mills, "Chief Programmer Teams, Principles, and Procedures," IBM Federal Systems Division Report FSC 71-5108, IBM, Gaithersburg, Md., 1971. </li>
</ul>
<ul>
<li><strong> On-line Resources<br>
<br>
</strong><strong><a href="http://en.wikipedia.org/wiki/History_of_software_engineering" target="_blank">Read an interesting summary of the History of Software Engineering… </a></strong> </li>
</ul>
</td>
</tr>
</table>
<br>
<br>
<a name="calendar"></a>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="right" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/images/Calendar.gif" width="114" height="37"></td>
<td width="15"> </td>
<td align="left" valign="top"><p> Every month you’ll find news here about local and national events that are of interest to the software community …</p>
<ul>
<li> <strong>Software Quality Calendar</strong><br>
<br>
There are many organizations that sponsor monthly meetings, workshops, and conferences of interest to software professionals. <strong><a href="/links/upcoming.html" target="_blank">Find out what’s happening…</a></strong></li>
</ul>
<ul>
<li> <strong>Workshops Offered by Software Quality Consulting</strong><br>
<br>
Software Quality Consulting offers workshops in many topics related to software process improvement. <a href="/seminars/courses.html" target="_blank"><strong>Get more info...</strong></a> </li>
</ul>
</td>
</tr>
</table>
<br>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td width="114" align="right" valign="top" background="/newsletter/images/RedSpacer.gif"><img src="/newsletter/images/AboutSQC.gif" width="114" height="37"></td>
<td width="15"> </td>
<td align="left" valign="top"><p> 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™ – so that organizations can consistently deliver quality software with promised features in the promised timeframe. </p>
To learn more about how we can help your organization, <strong><a href="/index.html?AboutSQC" target="_blank">visit our web site</a></strong> or <strong><a href="mailto:[email protected]">send us an email</a></strong>.</td>
</tr>
</table>
<br>
<br>
<table width="600" border="0" align="center" cellpadding="0" cellspacing="0" class="BodyText">
<tr>
<td align="left" valign="top"><p> I hope this newsletter has been informative and helpful. Your comments and feedback are most welcome. <a href="mailto:[email protected]"><strong>Send me your feedback…</strong></a></p>
<p>Thanks,</p>
<p> <img src="/newsletter/images/BusinessCard.gif" width="270" height="121" align="right"><img src="/newsletter/images/Signature.gif" width="90" height="68"><br>
Steve Rakitin<br>
<br>
<strong><a href="mailto:[email protected]">[email protected]</a></strong></p></td>
</tr>
</table>
<div align="center"><br>
<FONT class="Reference">Food for Thought, Predictable Software Development, Act Like a Customer,<br>
and ALAC are trademarks of Software Quality Consulting, Inc.<br>
Copyright 2006. Software Quality Consulting, Inc. All rights reserved.<br>
Graphic design by <B><U><FONT color=blue><a href="mailto:[email protected] ">Sage Studio</a></FONT></U></B></FONT></div>
<a name="bottom"> </a></body>
</html>