<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:pingback="http://madskills.com/public/xml/rss/module/pingback/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0">
  <channel>
    <title>Xenotar Software - Development</title>
    <link>http://www.xenotar.com/blog/</link>
    <description>Blog of Xenotar Software</description>
    <language>en-us</language>
    <copyright>Xenotar Software</copyright>
    <lastBuildDate>Fri, 17 Jul 2009 05:14:20 GMT</lastBuildDate>
    <generator>newtelligence dasBlog 2.1.8102.813</generator>
    <managingEditor>adriaan@xenotar.com</managingEditor>
    <webMaster>adriaan@xenotar.com</webMaster>
    <item>
      <trackback:ping>http://www.xenotar.com/blog/Trackback.aspx?guid=fac40714-fc55-45be-afa4-c6425a99727a</trackback:ping>
      <pingback:server>http://www.xenotar.com/blog/pingback.aspx</pingback:server>
      <pingback:target>http://www.xenotar.com/blog/PermaLink,guid,fac40714-fc55-45be-afa4-c6425a99727a.aspx</pingback:target>
      <dc:creator>Adriaan Putter</dc:creator>
      <wfw:comment>http://www.xenotar.com/blog/CommentView,guid,fac40714-fc55-45be-afa4-c6425a99727a.aspx</wfw:comment>
      <wfw:commentRss>http://www.xenotar.com/blog/SyndicationService.asmx/GetEntryCommentsRss?guid=fac40714-fc55-45be-afa4-c6425a99727a</wfw:commentRss>
      <body xmlns="http://www.w3.org/1999/xhtml">
        <p>
I have been reading <a href="http://www.joelonsoftware.com/articles/fog0000000036.html">Joel’s
painless functional specifications</a> a while back and thought it makes perfect sense
to write a functional spec, and wanted to write one one day when the opportunity comes
along. 
</p>
        <p>
And that opportunity came along last week when I decided it is time for a new project
for <a href="http://www.xenotar.com/company">Xenotar Software</a>. I’ve never written
a functional spec before so I am learning as I am going along.
</p>
        <p>
This week I started and mostly followed Joel’s recommendations. At first I though
it is going to be boring because I would rather write code than documentation, what
developer does not? But after a few paragraphs I realized that with the functional
spec I am also designing the software, and as I go along the whole project becomes
clearer. I am already seeing problems that I’m going face, and I’m already also thinking
about alternatives that might work better. I would usually find these problems only
after a hefty amount of code has been written, and the testing starts and the flow
does not feel right.
</p>
        <p>
At the beginning I thought to much of technical aspects of the implementation of features,
it took a while before realizing that I should focus more on how the product needs
to work and write that down, and not the implementation details.
</p>
        <p>
I am doing about a feature a day on the spec, but the developer in me wants to start
writing that code, so I need a bit of willing power to continue with the spec, and
everyday when I start, after that first sentence things just starts to flow. It is
also like the written words are arguing with me to say what I want to do does not
seem right.
</p>
        <p>
What I also like is when I am writing the next feature spec I can see clearly how
it clashes with some previous “design” flaws of previous features I’ve specked (is
this even a word?), so I can go back to the previous sections and make adjustments,
when it is going to be time to write the code for this I am not going to write code
that normally would be changed because of a later feature’s implementation. I know
it won’t be as simple as this, and I am sure if I am writing the code I am still going
to need to make changes because of previous written code, but I think those will be
technical things and not to do with the functional specifications of the project.
</p>
        <p>
I am hooked on this, I will never start a new project / feature again without a functional
specification. Now just to find someone to write it for me. ;)
</p>
        <img width="0" height="0" src="http://www.xenotar.com/blog/aggbug.ashx?id=fac40714-fc55-45be-afa4-c6425a99727a" />
      </body>
      <title>Writing a functional specification</title>
      <guid isPermaLink="false">http://www.xenotar.com/blog/PermaLink,guid,fac40714-fc55-45be-afa4-c6425a99727a.aspx</guid>
      <link>http://www.xenotar.com/blog/2009/07/17/WritingAFunctionalSpecification.aspx</link>
      <pubDate>Fri, 17 Jul 2009 05:14:20 GMT</pubDate>
      <description>&lt;p&gt;
I have been reading &lt;a href="http://www.joelonsoftware.com/articles/fog0000000036.html"&gt;Joel’s
painless functional specifications&lt;/a&gt; a while back and thought it makes perfect sense
to write a functional spec, and wanted to write one one day when the opportunity comes
along. 
&lt;/p&gt;
&lt;p&gt;
And that opportunity came along last week when I decided it is time for a new project
for &lt;a href="http://www.xenotar.com/company"&gt;Xenotar Software&lt;/a&gt;. I’ve never written
a functional spec before so I am learning as I am going along.
&lt;/p&gt;
&lt;p&gt;
This week I started and mostly followed Joel’s recommendations. At first I though
it is going to be boring because I would rather write code than documentation, what
developer does not? But after a few paragraphs I realized that with the functional
spec I am also designing the software, and as I go along the whole project becomes
clearer. I am already seeing problems that I’m going face, and I’m already also thinking
about alternatives that might work better. I would usually find these problems only
after a hefty amount of code has been written, and the testing starts and the flow
does not feel right.
&lt;/p&gt;
&lt;p&gt;
At the beginning I thought to much of technical aspects of the implementation of features,
it took a while before realizing that I should focus more on how the product needs
to work and write that down, and not the implementation details.
&lt;/p&gt;
&lt;p&gt;
I am doing about a feature a day on the spec, but the developer in me wants to start
writing that code, so I need a bit of willing power to continue with the spec, and
everyday when I start, after that first sentence things just starts to flow. It is
also like the written words are arguing with me to say what I want to do does not
seem right.
&lt;/p&gt;
&lt;p&gt;
What I also like is when I am writing the next feature spec I can see clearly how
it clashes with some previous “design” flaws of previous features I’ve specked (is
this even a word?), so I can go back to the previous sections and make adjustments,
when it is going to be time to write the code for this I am not going to write code
that normally would be changed because of a later feature’s implementation. I know
it won’t be as simple as this, and I am sure if I am writing the code I am still going
to need to make changes because of previous written code, but I think those will be
technical things and not to do with the functional specifications of the project.
&lt;/p&gt;
&lt;p&gt;
I am hooked on this, I will never start a new project / feature again without a functional
specification. Now just to find someone to write it for me. ;)
&lt;/p&gt;
&lt;img width="0" height="0" src="http://www.xenotar.com/blog/aggbug.ashx?id=fac40714-fc55-45be-afa4-c6425a99727a" /&gt;</description>
      <comments>http://www.xenotar.com/blog/CommentView,guid,fac40714-fc55-45be-afa4-c6425a99727a.aspx</comments>
      <category>Development</category>
    </item>
  </channel>
</rss>