Archive for the ‘Technology’ Category


Fixed Sprint Lengths Considered Harmful

Scrum advocates the use of fixed length sprints. The  length of the sprint can be adapted to balance between the need to release rapidly and allowing enough time to complete a useful amount of work in each sprint. Once an appropriate length is found, it generally stays the same.

While fixed length sprints are an improvement over waterfall style development in many respects, it imposes an artificial deadline for teams and this can cause inefficiencies and technical debt.

Sprints may have fixed lengths but user stories, on the other hand, are not homogeneous at all. Stories differ wildly in complexity and the time required to complete them. Teams will estimate their size and then commit to completing a certain number in a sprint. Seems reasonable enough but….

A scrum team will ALWAYS either over-estimate or under-estimate the amount of work that can be completed in a sprint.

This leads to one of four possible scenarios occurring.

Scenario 1: Team under-commits a lot

Team under commits a lot

If a team under-commits a lot, it is usually not serious as a new story can easily by in-scoped, which will lead to one of the other 3 scenarios being triggered.

Some teams may in fact work more slowly in order to prevent a new user story being in-scoped, either consciously or unconsciously. This risk, however, probably only applies to highly unmotivated teams.



Removing elements from dynamic arrays in D

Removing elements from associative arrays in D is easy, as we can use the handy “remove” method. When it comes to regular dynamic arrays, however, the story is a little different. There is no such method for removing elements and the documentation doesn’t make it completely obvious.

To complicate the situation more, the technique required depends on the version of D you are using.
DMD version 2.060 is out and with it comes the deprecation of std.algorithm.indexOf. Instead, std.algorithm.countUntil should be used in its place.

Here is an example:

import std.stdio;
import std.algorithm;

void main(string[] args) {

	auto items= ["item1", "item2", "item3"];
	auto index = countUntil(items, "item2");
	writefln("Index of 'item2' is: %d", index);
	auto mutated = remove(items, index);


It generates the following output:

["item1", "item2", "item3"]
Index of 'item2' is: 1
["item1", "item3"]

QTD compile error using DMD (Solved)

I’ve just been struggling to build QTD on my Ubuntu box.  QTD is the D programming language binding for the QT framework.  The error I was getting was:

CMake Error at cmake/FindD.cmake:41 (message):
  D compiler is not found
Call Stack (most recent call first):
  CMakeLists.txt:65 (FIND_PACKAGE)

This is strange because DMD is installed. After some investigation I found that the compiler isn’t found because the cmake file (cmake/FindD.cmake) searches for the version using a regex in the output to “dmd” (around line 13):

string(REGEX MATCH "(Digital Mars|DMD32) D Compiler v[0-9]\\.[0-9]+" dmd_version "${d_output}")

This is the guilty line. When I type “dmd” on my command line, the first line looks like this:

DMD64 D Compiler v2.060

This clearly doesn’t match the above regex. To fix the problem you can modify the regex above in the file “cmake/FindD.cmake” to look like the following:

string(REGEX MATCH "(Digital Mars|DMD32|DMD64) D Compiler v[0-9]\\.[0-9]+" dmd_version "${d_output}")

This fixes the problem.


Regex Performance in D Programming Language

Note: The problem described in this post was for DMD v2.054 and it no longer occurs with the more recent DMD v2.058  (see below for details or view the discussion at the D Forums).

I am currently working on a Ruby project that uses a lot of regexes on large volumes of text.  It is currently running too slowly, so I decided to try to optimise it by implementing the regex matching code in the D programming language.  D has given me a lot of joy (compared to C or C++)  by making things like string (with Unicode) handling a breeze without taking the performance hit of supposed “productivity” languages.  I painstakingly reimplemented my Ruby functions in D expecting a huge performance boost (actually I expected an order of magnitude performance jump) but instead I was shocked to see that Ruby outperformed my D code by a significant margin.  The Ruby implementation was finished after 80 seconds, whereas the D program required around 280 seconds using the exact same regexes and the exact same input.



Ikea’s Thin Client Woes

Lots of people tout the benefits of web applications over old fashioned fat clients or desktop applications. Yes, I agree that it solves the problem of rolling out software upgrades and requires little or no installation effort because the user just needs a web browser. People do tend to ignore the disadvantages of thin clients however. With the advent of software as a service it might be worth looking at those disadvantages before jumping on the bandwagon.


Ubuntu Upgrade Breaks Screen Resolution

I had a couple of problems recently upgrading Ubuntu. I temporarily bricked my laptop after pressing the upgrade Ubuntu distribution button in Hardy Heron (8.04). It cost me quite a few hours or time and caused quite a bit of stress to get it fixed. Since then I’ve avoided pressing the same button on my desktop (same Ubuntu version) until I really have a lot of time to kill.

My Firefox was hopelessly out of date on my desktop so I thought I would upgrade the installed packages. Thinking that this would be less risky than a full blown distro upgrade I pressed ahead. I’ve just spent an hour fixing my graphics settings after my graphics card driver stopped working (or something like that) and I thought I should share the solution because I’m sure others will have the same problem.



Carl and Steve

A “guest” post from Carl and Steve.  Enjoy…

Agile Software Engineering

Agile Software Engineering


Goals of Test Driven Development

Why should you adopt Test Driven Development?  The answer is actually more complex than many people think.

Of course we all want to have fully tested code to ensure that the code operates as expected.  We also want to ensure that any new features do not break existing functionality (regressions), but what other reasons are there?



Getting The Context Path (Without a HttpRequest)

Web programmers know that they shouldn’t go writing JSPs with the Context Path hard coded in them.

If you do the following:

<a href="/MyApp/path/to/controller/home.htm> Home </a>

You’ll notice that as soon as you decide to deploy your web application using a different name than “MyApp” then none of your links will work anymore.
To avoid this you need to get the context path from the HttpRequest object as follows:

<a href="<%=request.getContextPath() %>/path/to/controller/home.htm>

or by using a JSTL tag:

<a href="<c:url value="/path/to/controller/home.htm"/>"> Home </a>

What happens when you are rendering HTML in your Java code and you don’t have access to a HttpRequest object for whatever reason?



Introducing JTestConnect


A couple of months ago I finished the first version of JTestConnect. It is a tool for supporting development teams with their unit test strategies.

You can annotate your interfaces/classes with annotations describing how the object should be tested. The tool then sits in the build process and can interrupt a build if test classes/methods are missing.

Ideally, this would be added to a Continuous Integration build system to enforce test coverage of important classes.

A more detailed description of what it does can be found on the project home page.