Xenotar Software's Blog


Writing a functional specification

I have been reading Joel’s painless functional specifications 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.

And that opportunity came along last week when I decided it is time for a new project for Xenotar Software. I’ve never written a functional spec before so I am learning as I am going along.

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.

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.

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.

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.

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. ;)

Weekly update

Marketing strategy is in place for Direct Sell Assistant, Xenotar’s bookkeeping software for direct sales businesses. I have spend a lot of time putting this in place, so now I am on monitoring mode.

New Product Idea

I am also starting a new project for a new product. It is a licensing solution for .NET applications. While working with the ones that is out there I found there can be a bit of improvements.

We all know that when delivering software we don’t want to inconvenience the honest customer using our software. We also know if an user is not going to be willing to pay for our software he is going to try to find a workaround the licensing scheme, and if he does not get one, he probably will find another software solution. The best would rather focus on paying customers and keeping them happy then to try make your software uncrackable.

As a developer I would want to focus on the features of my software and not to worry about the licensing scheme that the application is using. If I can use the easiest possible way there is to implement the licensing scheme the better and more productive I can be. I also want my code not to get messy with licensing code and business rules code.

These are the most important parts I want to cover in my solution. Hopefully I can address them.

Let the planning begin.