Constituent Parts is a software development consultancy. We work mainly on, and around, the web. Our three main activities are:

• Building software for clients
• Helping our clients own software teams modify their development practices and processes
• Providing strategic consulting expertise in areas such as product research and design, practices and process, technology and technical architecure, and technical oversight of projects.

We make use of several basic practices. Because it's important not to make assumptions about what a client actually wants, we restate the brief to ensure that our understanding of the job is the same as the client's. We use the right tools for the job, to make sure that we deliver a solution appropriate to problem. We use just enough process to make sure that our clients know exactly what's happening with a project (and not so much process that there's more administration than productive work).

Restating the brief

We think it's really important not to make assumptions about what a client actually wants. We will formally restate the brief to a client to see where our standard assumptions and understandings differ. We then repeat the process until it yields a shared understanding of what is needed.

The side-effect of developing a genuinely shared understanding of the project is that it begins to establish what proponents of Domain Driven Design call a Ubiquitous Language, helping us to create better domain models, and recognise where the real problems are.

Most importantly, starting this way helps us to communicate with the client about their business clearly and unambiguously.

Just enough process

When a client commissions us to build software, or conduct research, we acknowledge a basic fact about our business: there are risks. There are risks that we might not understand what is wanted, or that a project changes while we're building it, that budgets or personnel will change, or that a problem is harder than it first looked.

It's also important that a client is able to change their mind: an inevitable consequence of beginning to use software is that you realise more about the problem you were trying to solve. Our approach is to acknowledge the risks and realities and take sensible steps to mitigate them. We are firm believers in agile methods as the way to deal with this situation. Agile practices and processes, at their best, provide handles which deal with the two core sources of risk in software: change, and communication. We've been working with agile since 2005, and the techniques have proven themselves over countless projects, large and small, with teams and as a lone developer.

The other key risk is in communication between us and a client. Our approach means that at no point do we spend weeks (or even days) silently beavering away. Instead, with regular, frequent, new builds for a client to use we can talk regularly with a client, responding quickly to queries and feedback. With a list of prioritised features it's always obvious what we're working on, and what we'll be working on next. If a client realises they need to reprioritise, reduce the scope of a project, or make any other changes, the state of the project is made as explicit as possible, and the client has all the information they need to work with us to make those changes.

The right tools

We favour tools which allow us to work quickly, and which don't burden us with technical or process baggage.

We use the Behaviour Driven Development (BDD) approach to support our process and communication goals, making heavy use of the acceptance-test-automation framework Cucumber and the lower-level test-automation framework RSpec. We think that this results in better designed and better factored code, fewer bugs, and much faster resolution of the few bugs which do slip through. We think that our code is easier to change as a result, which makes it much easier to deal with even quite significant changes in direction or focus during a project.

Different projects require different approaches, and we try to use the best tools to ensure our approach to a project is the right one, and that it works.

For projects requiring a custom web application or CMS we usually use Ruby on Rails, which we've been using since late 2005. Other projects require different tools, and we have experience with several of the major blog-derived CMS systems, as well as extensive experience with Ruby, Python, Javascript, SQL, and deployment on Linux-based systems.