<?xml version="1.0"?>
<rss version="2.0">
<channel>
  <title>Coding the Architecture - newbie tag</title>
  <link>http://www.codingthearchitecture.com/tags/newbie/</link>
  <description>Software architecture for developers</description>
  <language>en</language>
  <copyright>Coding the Architecture</copyright>
  <lastBuildDate>Mon, 21 May 2012 09:41:00 GMT</lastBuildDate>
  <generator>Pebble (http://pebble.sourceforge.net)</generator>
  <docs>http://backend.userland.com/rss</docs>
  
  
  <item>
    <title>Where&#039;s the coffee machine?</title>
    <link>http://www.codingthearchitecture.com/2007/11/16/wheres_the_coffee_machine.html</link>
    
      
        <description>
          &lt;p&gt;I have recently moved into a technical architect &lt;a href=&#034;http://www.codingthearchitecture.com/tags/role/&#034;&gt;role&lt;/a&gt; at a new client.  Over the last month or so, I have asked lots of questions.  Here are some that I found particularly useful...
&lt;/p&gt;
&lt;p&gt;
&lt;ul&gt;&lt;li&gt;&lt;strong&gt;Who is that?&lt;/strong&gt; - I always ask for a new client&#039;s organisation chart, or better still, find someone to take me through the hierarchy on a white board.  As an architect, your sphere of influence is much greater and you are expected to interact with many more stakeholders - multiple project managers, infrastructure / networking techies, IT directors, people from all corners of &#034;the business&#034;, testers, suppliers / prospective vendors, your client&#039;s clients, etc.  Knowing all their roles and places in the organisation is key to understanding their &lt;a href=&#034;http://www.codingthearchitecture.com/2006/02/27/dont_forget_the_people.html&#034;&gt;motivation&lt;/a&gt;.
&lt;/li&gt;

&lt;li&gt;&lt;strong&gt;How urgent is that really?&lt;/strong&gt; - Work comes at me from all directions with little warning.  People want some of my time to review a design, troubleshoot a potential prod issue, dissect some smelly code, run a perf test, optimise an ailing query, and so on.  I am essentially a single processor unit, so managing the constant context switching has been one of the hardest skills to pick up.  As always, prioritising the tasks is critical.  In my experience, it is only the person at the top of the org chart (CTO or IT Director) who has enough of a neutral overview to do this properly.&lt;/li&gt;

&lt;li&gt;&lt;strong&gt;Are you hungry?&lt;/strong&gt; - Go out for lunch.  Often.  People are more inclined to accept a lunch or coffee invite from the new guy, and I&#039;ve found that this is a very useful information gathering tactic.  Once out of the office, conversation is generally more candid, and discussions won&#039;t get interrupted by IM, email, badgering colleagues and ringing phones.&lt;/li&gt;

&lt;li&gt;&lt;strong&gt;OMG, how long is that method?&lt;/strong&gt; - OK, so a bit of a contrived question, but worth emphasising.  I&#039;ve gained the most insight into my client&#039;s business, their challenges and the development team&#039;s strengths by pulling apart the codebase.  I have had to dial down my natual pedantry level and learn to concentrate on the big ticket &lt;a href=&#034;http://www.codingthearchitecture.com/tags/nonfunctionalrequirements/&#034;&gt;non functional requirements&lt;/a&gt; such as security and performance, whilst not worrying about the odd unused import.&lt;/li&gt;

&lt;/ul&gt;
&lt;/p&gt;
&lt;p&gt;
I&#039;d be interested to see what questions others ask when they start on a new project / client...&lt;/p&gt;
        </description>
      
      
    
    
    
    <category>What is the the role of a software architect?</category>
    
    <comments>http://www.codingthearchitecture.com/2007/11/16/wheres_the_coffee_machine.html#comments</comments>
    <guid isPermaLink="true">http://www.codingthearchitecture.com/2007/11/16/wheres_the_coffee_machine.html</guid>
    <pubDate>Fri, 16 Nov 2007 08:36:00 GMT</pubDate>
  </item>
  
  </channel>
</rss>

