Beyond code

Getting started with a project is always difficult. Either you start as an experiment and quickly end up trying to stuff a world of functionality into your product, or you work in an organisation where someone with influence says ‘we need a product that does this’.

No matter what project management strategy you maintain, you need to do some ground work before you can actually start a project to deliver product X. One of the first steps is to sit down with the stakeholders and see if it is even a good idea to create this product.

Now you are faced with the task of getting the group of people together whom you should consider the stakeholders, but how do you determine them? You cannot just point to a bunch of people and say ‘you are a stakeholder’, with great certainty you will be able to say that whatever you think up will need to be redone later because you did not have the right people deciding what to do.

So, what should you do? I have seen companies that have said ‘just make it and we’ll review it later’; this approach basically guarantees that whatever you create, it will be wrong because you have absolutely no information to work with. Other companies have so-called ‘Product Managers’, people dedicated to caring for a product, in a non-operation sense. Having only these people around the table when you try to decide what should be done or if it should be done at all will also always result in absolute failure.

What then? So far, for me, the simpelest thing to use is to look at the work domains surrounding the new product to get a list of stakeholders that can tell you something usefull about the product you wish to build.

Lets take as an example a novel product called a ‘Blog’. Someone hires you to determine the requirements of this product. In order to get a sense of the domains surrounding the product you ask the initiator what they see when talking about a ‘Blog’.

Most likely the initiator will say that they expect someone to ‘Write’ something so that others can ‘Read’ it. Great, writing and reading are your first domains, now you go over to the person (or people) that have been marked as ‘writers’ and ask them what they expect at this point. They will tell you that they expect to ‘write’ something, have it ‘reviewed’, ‘published’ and ‘announced’ to the outside world. They also expect that readers can leave ‘comments’ and that they can respond to them.

After doing a little bit of research into the subject you also notice there are several standards for certain parts of a ‘Blog’, namely ’syndication’ and ‘trackback’.

If you put all this information into a simple context diagram (with some images from technorati, gravatar, wordpress and rss) you see a nice overview of who, at this point, are your major stakeholders.

The context of your product

It does not take a lot of effort to find out what the major domains of work are related to your product, which will then lead you to your stakeholders.

These stakeholders you can call together for a project kick-off meeting to determine how to move on; a nice subject for the next time!

Code, Requirements, Software Requirements, Software, Stakeholders

I installed the really awesome Wordpress mobile edition plugin, which now gives mobile users a much friendlier interface and makes it a lot easier to read my blogposts!

If you have a wordpress blog and you have mobile device users (iphone, mobile phone) then I would suggest also installing this plugin, it was quite easy to do.

Blog, Code, Software Blog, plugin, wordpress

As a regular reader of reddit’s programming section I tend to be amazed about the number of people who seem to have something against requirements.

Wikipedia defines a requirement as follows:

In engineering, a requirement is a singular documented need of what a particular product or service should be or do. [...] . It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user.

In the years that I have now spent in software engineering I have seen many different approaches; from classic waterfalls, to the currently hip Scrum model.

No matter which approach you take you do need to know a set of requirements before you actually can start doing anything, including gathering the requirements.

• What is the purpose of this project.
• What is the scope of this project.
• Who are the stakeholders of this project.
• What are the constraints of this project.
• What are the risks of this project.

Purpose

This is a short, quantified statement of what the resulting product should do and what it means for your business. This simple statement should make clear why the company is justifying the investment in the product and will help keep focus while gathering requirements.

Scope

The scope of the work is defined by the business area affected by the installation of the product (the roll-out). You need to understand these areas in order to properly specify the appropriate product.

Stakeholders

The stakeholders are the people with an interest in your product; the customer who requested the product, the users who will be using the product and all the other people with knowledge needed to gather all the requirements for the product.

Constraints

No product can be made with infinite budgets, time or technology; these aspects create the constraints in which the project should create the product.

Risks

Every product brings along risks, these should be clear and understood before continuing.

Go / No-Go

All of the above result in a document which can be used at a project blastoff / kickoff to determine if the project has any chance in succeeding at all.

Gathering requirements

In order to understand what is actually needed from a project you, after getting a go, need to gather all relevant functional and non-functional requirements.

For many projects this can be done iteratively, often you will find a requirement only by already doing some design or development work, but nontheless they should all be documented else you will always end up with discussions and questions about some aspect of the product after a lot of work, time and money has been spent.

When you are dealing with outsourcing (which I do as part of my current job) you should always strive to have as many requirements defined as possible in order (for both parties) to have a clear understanding what work should be done and what the ultimate goal of a project is.

Volere

In order to get more organized in this area I started to study up on requirements processes and have selected the Volere requirements process as a basis for my own work. The process is described in full in the book Mastering the Requirements process.

Now that the requirements process is a much larger part of my daily work I think it would be a good idea to devote a series of articles on this process and to show how I put a personal spin on the Volere process itself.

It should be clear that I am a great proponent of software requirements, if done appropriately within the context of a company and project; defining all requirements up front in a Scrum process is not a good choice as is not defining enough in an outsourcing process.

Requirements, Software process, Requirements, Software, volere

I have been a contributor to code swarm since it has become open source. Mainly I have been involved in making the OpenGL part of it work nicely. Today I ran into a nice code_swarm video from the Rails project in which I noticed some really nice avatars in the visualisation, please see the video below.

This is actually an enhanced implementation of code_swarm by rictic! I added his project to my github watch list, perhaps the feature is a nice one to merge back into the main code_swarm project.

Code avatar, Code, code_swarm, Java

It has been a long while since my last blog post. A lot of stuff has happened in my personal life, but I have a feeling that it has calmed down significantly enough for me to enjoy my life once again.

I have been reading some books lately, all programming related:

iPhone SDK Development: this is a Beta book from the pragmatic programmers group… it is not yet finished but what I read so far is quite interesting. The book tries to easy you into iPhone development, it kind of succeeds, however since it is a beta book it has a lot of small errors…. and that makes it hard to follow along, since you are regularly trying to find out why something is not working and thinking you did not pay enought attention :S…. luckily the errata section on the website helps a lot! In the end this will be a great book to start your own development, I am sure!

Programming Erlang: a very good book to get you into Erlang programming! I would recommend this book to anyone interested in learning Erlang. The book starts with a gentle introduction into the language itself and the change of mindset needed with functional programming after which it nicely covers everything from distribution of code over several nodes, storing data in the various database possibilities and creating distributed, fault tolerant and concurrent systems using the Open Telecom Platform (OTP).

Erlang in practice: not really a book, it is a set of screencasts exploring the process of writing an erlang chat server. Takes you through all the steps; setting up, distributing, persisting and adding REST support.

Although the iPhone/Objective-C book is quite interesting I find that I am more attracted to writing server side software. I guess it is because server side software is more of an boolean logic then interfaces (either it works, or it doesn’t).

Although the Erlang package comes with a great Emacs mode for editing erlang software it misses 2 things:

The mode uses Tempo snippet support, while I have found that YA Snippet provides far superior templating.

The other is that flymake is quite a necessity I think. Flymake provides on-the-fly syntax checking of your source code.

I have added the following configuration to my emacs setup to enable it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

(add-to-list 'load-path "path-to-erlang-package-emacs-mode")
(require 'erlang-start)
 
(add-to-list 'auto-mode-alist '("\\.erl?$" . erlang-mode))
(add-to-list 'auto-mode-alist '("\\.hrl?$" . erlang-mode))
 
(require 'flymake)
 
(defun flymake-erlang-init ()
  (let* ((temp-file (flymake-init-create-temp-buffer-copy
		     'flymake-create-temp-inplace))
	 (local-file (file-relative-name temp-file
		(file-name-directory buffer-file-name))))
    (list "path-to-eflymake" (list local-file))))
 
(add-to-list 'flymake-allowed-file-name-masks '("\\.erl\\'" flymake-erlang-init))

Lines 1 and 2 setup the erlang mode, 4 and 5 associate this mode with .erl and .hrl (erlang records) files, line 7 loads up flymake and lines 9 up to and including 14 tell flymake how to check erlang files for syntax. I use the eflymake script for this job. Line 16 tells flymake to use this for .erl files.

The eflymake script mentioned is an escript script:

1
2
3
4
5
6
7
8

#!/usr/local/bin/escript
-export([main/1]).
 
main([File_Name]) ->
    compile:file(File_Name, [warn_obsolete_guard, warn_unused_import,
                             warn_shadow_vars, warn_export_vars,
  			     strong_validation, report,
  			     {i, "../include"}]).

This greatly simplifies the writing of code using our favorite editor ;). During the screencasts of Erlang in Practice (mentioned above) you see the benefit of this extension. The author starts out with a clean Emacs installation it seems and over the various screencasts you see that he adds this extension. In the first couple of sessions you see him make some small mistakes and lateron you see that Emacs warns him and he fixes the code before he gets bitten by it.

While learning Erlang I found that I have a new-found love for server programming. I was kinda dumbed down by the many years of Java programming and was loosing interest in programming server-side really, now with an injection of a new language and “new” ideas I am totally excited to be in this field again… quite awesome what taking some time to learn something new can bring with it!

So, expect some Erlang posts the coming time. I am trying to think of a nice example to illustrate some of the niceties of Erlang and the OTP.

Code, Emacs books, Emacs, erlang, objective-c