code « Company Blog

Archive for the ‘code’ Category

Billing with Integrity (part 3)

More likely with fixed price projects...

(You may want to read parts one and two first).

This time we’ll look at four variables of software development which always apply to any software project. We’ll see how they interact with each other, how a fixed price project model is affected by them, and a potential end result which is often a reduction in quality and more bugs.

So what are these four variables of development? Briefly, they are:

Scope – the size of the project.
Time – the amount of time taken to get a project done
Cost/Resources – the amount of money the project is costing
Quality – the end quality of the project (i.e. how robust it is)

You can fix two or three of these variables but it isn’t possible to fix all four.

For example: suppose a feature will take four days to do properly. If you want to take two days over it, then you can either:

Increase cost/resources (add more developers, not generally a good idea)
Reduce scope (cut the requirements for the feature in half)
Rush the work (stay up late, or just code too fast) which then litters the code with bugs, reducing quality.

Fixed price projects try and fix all four of these: “I want this spec, by this date, costing this much. Oh, and no bugs.” So when the inevitable happens and project scope changes, what can be done? The cost is already fixed, or only changeable through a long-winded change process, and there may simply be no money to throw at the project. The deadline could be extended (increase time), but that then leaves the developer out of pocket if the cost stays the same, and the client is unlikely to be happy.

Often the only option is that a developer will revert to rushing the work, to try and get it done as quickly as possible. This leaves a project that looks just great on the outside, and may work ok when delivered to the client, but after a few months it becomes obvious that it only just hangs together. The client might request a change that appears simple on the outset, but because the original work was rushed, the work takes much longer than the developer thought and exposes underlying bugs. Automated tests are often skipped when work is rushed, which further reduces confidence in the codebase when something needs to change.

Conclusion: Don’t fix project price and scope

So, in conclusion, a long fixed price project for a fixed spec is counter-productive. As we’ve already seen, it can allow developers to take advantage of clients, it pits the client and developer against each other, and in practice it fosters bugs in software. Change is the natural state of a software project, and by definition, this model is incompatible with change.

Next time we’ll look at variable billing, by charging for small increments of time. We’ll see how this model interacts with the four variables discussed above, and some of the advantages and disadvantages it poses to both clients and developers.

Tune in next time for a discussion on variable billing (you may want to subscribe for the latest updates). If you’re in a hurry for an “answer”, you could always peek at our pricing pages if you want to know how we bill :) Thanks to Kent Beck’s excellent essay on Optional Scope Contracts (PDF) for many of the ideas in this series and to Ngọc Hà for the photo.

Posted on: Friday, January 23rd, 2009 Posted in business, code | 5 Comments »

Rails and Merb to merge: an opinion

I’m glad Rails and Merb have decided to merge. Rails is the framework we use every day to build systems for our clients, and having the benefits of Merb without having to support two frameworks is a big win for us.

Merb was created originally because of some well known shortcomings of the Rails framework, most notably surrounding uploading files to a website. Since its creation it grew into a full framework in its own right and became a sort of ‘Rails done right’ in the eyes of many. Now, the best bits of merb will become Rails 3, and some of the best ruby coders in the business will be working on the framework we use every day. That’s a great thing for Rails users everywhere.

Despite the claims of some, it’s not about one set of people ‘winning’ and one ‘losing’. Ultimately the combined codebase is the real winner, and therefore the people that use it, such as companies like ourselves. We’ll certainly do all we can to support the move here.

This sort of behaviour is almost unprecedented for open source software: often open source communities are more characterised by petty infighting than bipartisanship. It’s shown that those on both sides of the fence are pretty big people, and willing to put aside personal differences. The result (I hope) will be a combined framework that’s leaner, meaner and with a clearer future in front of it. We’ll be watching with interest in the coming months.

Posted on: Monday, January 5th, 2009 Posted in code | 21 Comments »

Genetic Algorithms: Approximating Fine Art

70000 attempts in...

For a bit of fun, I decided to re-implement Roger Alsing’s approximation of the Mona Lisa in Ruby (my language of choice).

Rather than the brute force approach taken by the original implementation, I’ve gone for a full genetic algorithm solution, with crossover, mutation and population propagation. It’s been lots of fun :)

If you’re interested, grab the code here. It’s all open source: if you fancy modifying it, feel free to do so!

Update: Added work in progress image.

Update: Replaced work in progress image. This one only uses 50 triangles!

Posted on: Thursday, December 11th, 2008 Posted in code, random | 10 Comments »

Starting at Eden

Not many people can honestly say that they are actually doing their dream job. Many people have dreams and aspirations, and somewhere along the line they end up in a completely different destination. Life just has that way of sidetracking you, without you even noticing. That being said, on September 21st 2008, I walked into my dream job. Everything would be plain sailing from here on, the hard work had already be done getting here in the first place, right? Wrong.

From the first hour I realised that that these guys (and girl!) were good… really good. Not just that, they were talking in a completely different language to that which I was accustomed. Agile Development? Behaviour Driven Design? RSpec? Outside-in? Fixing broken windows… isn’t this a computer company? To say I was confused and a little scared at this point, would be an understatement. I still had a very big mountain to climb, in fact, my journey had only just started.

However over the last few months that I have been here, I have really started to grasp a lot of these concepts. Not perfect, or master them (that takes time and practice) but the value of them and how applicable they are to modern software design has blown me away. The concept of Agile Development and BDD isn’t completely strange and abstract, in fact, it’s quite simple:

Write a story to explain the feature you are adding. (This can be done by the developer or customer)
Run the story (it involves Cucumbers, i’ll explain some other time)
The story fails (no code yet)
Write a spec for the code that you will finally implement (This is the second layer of testing)
Write code

The first 4 steps can be repeated a few times before any real code is actually written. When you do come to write code though, you know it works. How? The specs tell you so. It’s magic. Compare this to how I was taught software development in University:

Write a design document (This explains the entire system and its individual components)
Create UML diagrams and User Specifications for every Class in the system and how they interact
Write code

Fewer steps, it must be quicker. What I didn’t mention was that the first two steps can take months alone. Often by the time that you actually come to write some code, a feature of the applications design has now changed, this means that has to be re-written and the diagrams all updated. Further delays. This monolithic approach is largely inefficient and frustrating!

So Agile Development works out better for the customer and better for us programmers (we actually get to do what we love doing!). Coupling that with strict testing at every step ensures fewer bugs and greater flexibility. You can approach each new feature/problem with confidence knowing that if any change you make breaks another part of the system, it will be caught by the tests failing. This is why the staff at Eden actually love doing what they do. They get to write awesome software, and have fun doing so. Compare this with the Games industry which is full of programmers who are overworked and burnt out. They were in what they thought was their dream job, but really wasn’t. I still have a mountain to climb to reach my new goals, but I’m having a lot of fun doing so!

Eden is a great company, with extremely talented staff. We have lots of really interesting projects spanning many different industries. I think this mountain will be quite fun to climb :)

Posted on: Monday, December 8th, 2008 Posted in bdd, business, code, rspec, testing | Comments Off

Under the hood: RSpec as your early warning system

This article is part of our ‘under the hood’ series, where we examine coding concepts and techniques related to how we build our products and services for our clients. If you’re of a technical bent, then do check out other articles as they appear in our ‘under the hood’ category.

One of the most useful aspects of RSpec and BDD is how it can highlight areas of your code that are obvious targets for improvement.

When we write our specs before our code we are effectively writing the API, the contract that our code must fulfill. It’s often the case that if this contract is hard to write, or just looks clumsy, then there may be a better way to express it. This makes RSpec our first way of detecting code smells.

Perhaps the easiest type of code smell to detect with RSpec is Law of Demeter violations. Imagine a simple Ruby on Rails task management application. Tasks can be owned by Users. There may be many places where we would want to show who owns what Task. The simplest way to do this in Rails would be to use a belongs_to association to expose the attributes of the User to the Task. This makes it trivial to get the name of the user who is assigned to a task:

class Task < ActiveRecord::Base
  belongs_to :owner, :class_name => "User"
end

# to get the owner name:
task.owner.name

While this is easy to write, it would make our specs more complex. Anywhere we wished to mock the name of the owner we would have to write something like the following:

task.stub!(:owner).and_return(mock_model(User, :name => "Bob Smith"))

There’s a lot of noise in this line. We’re creating a mock object just to produce the name of the user. Typing and maintaining test code like the above just seems unnecessary — we’re mocking more than we need. Perhaps worse, it doesn’t express our intentions clearly. We’re asking the task to return its owner, then asking that owner to give us its name. Instead of this approach, we can define the contract as we go and we can actually express our intention:

task.stub!(:owner_name).and_return("Bob Smith")

This makes our tests look tidier, but it actually has a more beneficial side effect. Even though we now have to write more code (speccing then adding the owner_name method to the Task class), it’s now the Task’s job to find the name of its owner. This makes our code more maintainable. For instance, imagine that not every task has an owner. With our original code, anywhere we explicitly used the owner association we would have to change the code to:

(task.owner.nil? ? "No Owner" : task.owner.name)

If this was used many times throughout our code base, we’ve suddenly got a large number of places to find and test this code. By defining the owner_name method early we avoided this problem because there’s only one place that now has to deal with the messy business of finding the name of the owner. Our other specs and stories aren’t broken because they can still happily call the owner_name method without worrying about how this is actually handled.

By using RSpec to help us separate out what information we want from how we get this information, we’ve made our codebase just a little bit cleaner and more maintainable.

Posted on: Friday, December 5th, 2008 Posted in bdd, code, refactoring, rspec, testing, under the hood | Comments Off

Personal victories

I love it when you can refactor a bulky, ugly function down into one line. It always makes me very happy indeed. Here is my solution for outputting a person’s name in a nice format, taking title, initials, first name, surname, suffix. Initials take precedence over first name.

This is how i did it originally:

  def contact_display_name
    returning String.new do |output|
      output < < title + ' ' unless title.blank?
      if initials
        output << initials + ' ' unless initials.blank?
      else
        output << first_name + ' ' unless first_name.blank?
      end
      output << surname + ' ' unless surname.blank?
      output << suffix unless suffix.blank?
      output.strip!
    end
  end

Rather too long-winded for my liking. I managed to refactor it down to this:

def contact_display_name
    [title, (initials? ? initials : first_name),
      surname, suffix].delete_if(&:blank?).join(' ')
  end

Of course, it is another advantage of behaviour-driven development, that i had already specced out what i wanted to happen, and i could use the specs to ensure that my two versions of the function were equivalent. See below for the specs that verify the behaviour.

(more…)

Posted on: Friday, November 21st, 2008 Posted in bdd, code, refactoring | 2 Comments »

Cucumber is a joy

Cucumber, the replacement for the rspec story runner, is an absolute joy to use. It only takes maybe a few minutes to move an old set of stories over to Cucumber features, plus you get full language support, something one of our coders might have taken slightly too far :-)

We’ve now switched all our active projects over. I highly recommend you do the same if you haven’t already – it’s a real step closer for us to the ideal situation where customers can collaborate on the text their own stories. Aslak and the rest of the team have a lot to be proud of.

Posted on: Friday, November 14th, 2008 Posted in bdd, code, rspec | Comments Off

Taste can be acquired

Acquire Taste by DHH got me thinking.

Having ‘taste’ is a really important skill you can have as a developer – even if you don’t classify yourself as a ‘designer’. It’s a great thing to be able to add User Interface elements in just the right place, or code a feature up that just feels right. When a piece of software has been crafted lovingly, everyone loves to use it.

Having taste as a developer is a bit like what my wife says about being tidy around the house. Now, I’m not a naturally tidy guy, but I’m learning to be; mostly because if I wasn’t I would drive her crazy! Sometimes the problem is that I just don’t see the mess, but that’s really laziness. It’s because I’ve not yet learned to take a second look each time and judge my attempt at cleaning the kitchen with her standards. Usually at that point I see where I could do better.

It’s the same with code/feature design. Most of the time it just takes another look, and not settling for just “good enough”. It’s a choice, and making the right one will make someone else that much happier with the work we do. Food for thought.

Posted on: Tuesday, October 21st, 2008 Posted in code, design | Comments Off

Coding is like gardening...

Archive for the ‘code’ Category

Conclusion: Don’t fix project price and scope