<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: INFOSEC, Legos and Safes - Oh My!</title>
	<atom:link href="http://www.riskbloggers.com/ljh/2006/12/infosec-legos-and-safes-oh-my/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.riskbloggers.com/ljh/2006/12/infosec-legos-and-safes-oh-my/</link>
	<description>Security Wisdom Ahead of the Curve</description>
	<pubDate>Mon, 12 May 2008 00:07:11 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Kurt.Seifried</title>
		<link>http://www.riskbloggers.com/ljh/2006/12/infosec-legos-and-safes-oh-my/#comment-95</link>
		<dc:creator>Kurt.Seifried</dc:creator>
		<pubDate>Fri, 22 Dec 2006 07:39:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.riskbloggers.com/ljh/2006/12/infosec-legos-and-safes-oh-my/#comment-95</guid>
		<description>I think you hit the nail on the head. I've heard of, and been involved with several software projects as a technical writer, where writers, or I was brought in towards the end of the project in order to document what happened. At this point it's usually a bit late, they built it, and now want a set of blueprints. Typically the documentation ends up being written from the perspective of what it should be doing (because you end up asking the software developer "how is this supposed to behave?"), as opposed to actually what it does do.

So you now have a product that may or may not do what it was intended to do, assuming the people building it knew what it was they were trying to do, which they probably aren't 100% certain of (feature creep is so much fun).

I think I'm going to go play with my legos now.</description>
		<content:encoded><![CDATA[<p><!-- google_ad_section_start -->I think you hit the nail on the head. I&#8217;ve heard of, and been involved with several software projects as a technical writer, where writers, or I was brought in towards the end of the project in order to document what happened. At this point it&#8217;s usually a bit late, they built it, and now want a set of blueprints. Typically the documentation ends up being written from the perspective of what it should be doing (because you end up asking the software developer &#8220;how is this supposed to behave?&#8221;), as opposed to actually what it does do.</p>
<p>So you now have a product that may or may not do what it was intended to do, assuming the people building it knew what it was they were trying to do, which they probably aren&#8217;t 100% certain of (feature creep is so much fun).</p>
<p>I think I&#8217;m going to go play with my legos now.<!-- google_ad_section_end --></p>
]]></content:encoded>
	</item>
</channel>
</rss>
