    <rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/">
     <channel>
        <title>ACCU  :: Letters: The Invisibility of Software Design</title>
        <link>https://members.accu.org/index.php/journals/219</link>
        <description>Professionalism in Programming</description>
        <dc:language>en-us</dc:language> 
        <dc:creator>Administrator</dc:creator> 
        <admin:generatorAgent rdf:resource="http://www.xaraya.org" /> 
        <admin:errorReportsTo rdf:resource="mailto:webeditor@accu.org" />
       <sy:updatePeriod>hourly</sy:updatePeriod>
       <sy:updateFrequency>1</sy:updateFrequency>
       <docs>http://backend.userland.com/rss</docs>


        <h2>Journal Articles</h2>


<div class="xar-mod-head"><span class="xar-mod-title">Overload Journal #61 - Jun 2004 + Letters to the Editor</span></div>

<table border="0" cellpadding="1" cellspacing="0">
    <tbody>
    <tr>
        <td valign="top">
            Browse in :
       </td>
       <td valign="top">

                                            <a href="https://members.accu.org/index.php/journals/">All</a>

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c76/">Journals</a>

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c78/">Overload</a>

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c151/">61</a>
                    (10)
<br />

                                            <a href="https://members.accu.org/index.php/journals/">All</a>

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c184/">Journal Columns</a>

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c186/">LettersEditor</a>
                    (132)
<br />

                                            <a href="https://members.accu.org/index.php/journals/c151-186/">Any of these categories</a>

                    -                        <a href="https://members.accu.org/index.php/journals/c151+186/">All of these categories</a>
<br />
</td>
   </tr>
   </tbody>
</table>




<div class="xar-error">
   <p>
 <strong>Note:</strong> when you create a new publication type,
the articles module will automatically use the templates
<em>user-display-[publicationtype].xt</em>
and <em>user-summary-[publicationtype].xt</em>.
If those templates do not exist when you try to preview or display a new article,
you'll get this warning :-)  Please place your own templates in themes/<em>yourtheme</em>/modules/articles . The templates will get the extension .xt there. </p>
</div>
<div class="xar-norm xar-standard-box-padding">
   <h1><strong>Title:</strong>&nbsp;Letters: The Invisibility of Software Design</h1>
<p><strong>Author:</strong>&nbsp;</p>
<p>
<strong>Date:</strong> 01 June 2004 14:26:10 +01:00 or Tue, 01 June 2004 14:26:10 +01:00</p>
<p><strong>Summary:</strong>&nbsp;</p>
<p><strong>Body:</strong>&nbsp;      <p>Dear Mark,</p>

      <p>I read your editorial in April&#8217;s Overload with a
      sense of depressing agreement. I have been in the industry
      for around ten years and I have worked in most phases of the
      software development cycle, from requirements through to some
      postinstallation customer support. I have worked as a
      programmer, a designer and as a consultant advising companies
      on development strategy and technology policy. I think that I
      am just getting to the point were I can understand what is
      going on and might have something to say about it.</p>

      <p>I have been appalled by the lack of learning from
      experience that is evident in the industry but I am not sure
      that it is entirely down to the practitioners. I am beginning
      to think there is a structural problem with IT that
      exasperates people&#8217;s tendency to want to reinvent
      everything and I think that it contributes and fuels the
      &#8216;follow the hype&#8217; climate.</p>

      <p>I think that the problem lies in the invisibility of
      software design in the delivered product. I think that this
      invisibility has at least two important consequences:</p>

      <p>Firstly, it means that good design is not recognised by
      the users because they can not see it. There is no end-user
      pay-back for elegant design. Contrast this with civil
      engineering where design is very visible e.g. it is simple to
      see that the Millennium Bridge has a wonderfully elegant
      design. This means that the industry as a whole does not
      place much emphasis on quality of design, so practitioners do
      not see it as important either. Therefore if it is not
      important why learn about how others have done it in the
      past?</p>

      <p>Secondly, it means that it is difficult for those that do
      want to learn to know where to start. You can gain a great
      deal of information about civil engineering and structural
      design by looking at buildings, bridges, etc. In fact the
      conversation of many architects will be peppered with
      references to this building or that bridge.</p>

      <p>Things are different for software engineers, there might
      be brilliant examples of software design installed on the
      computer I am using right now and I would never know. Even
      worse than not knowing, even if I did know I could not look
      at them because the source code will be secret.</p>

      <p>This issue of secrets constantly nags at me. I think that
      the software industry&#8217;s obsession with intellectual
      property is an important reason for the glacial pace of its
      advance. As an industry we keep things private and secret
      more than any other (at least in my experience). How is a
      rookie programmer supposed to learn how those that went
      before him did things if everything they produced is hidden
      behind a cloak of secrecy? Unless he is lucky enough to work
      in a very experienced team he is left blind. This point is
      made clear in your editorial: unless I am lucky enough to
      know your friends how could I know that they had solved the
      problems of the transactional programming model 25 years ago?
      It is easy to see how medieval architects solved the problems
      of load on cathedral walls, you can go and look at the flying
      buttresses!</p>

      <p>One light on the horizon is the increasing use of Open
      Source Licensing. This has led of a large body of software
      being made available for those that want to learn. I for one
      have found that I have learnt more about software design from
      my involvement in a number of Open Source projects in the
      last few years than I have in most of my professional
      programming jobs. I have also found that I am more motivated
      to do an elegant design and professional coding job if I
      think that many people are likely to look at my code. I
      realise, that as a professional, I should always be motivated
      to do this, but I, like most practitioners in our industry,
      am only human.</p>

      <p>So my advice to a new programmer that wants to
      &#8220;stand on the shoulders of giants&#8221; rather than be
      condemned to &#8220;reinvent the wheel&#8221; is this: Ignore
      just about everything the software vendors tell you, listen
      to the old hands on your team and spend some of your spare
      time reading and contributing to Open Source Software.</p>

      <div class="literallayout">
        <p>Regards<br>
        Richard&#160;Taylor</p>
      </div>
</p>
<p><strong>Notes:</strong>&nbsp;</p>
<p><em>More fields may be available via dynamicdata ..</em></p>
</div>
</channel>
</rss>
