We believe in building what is necessary, what makes people productive, without bogging them down with minute detail. We believe it is these details that holds up software, stops real world feedback and eventually makes software bloated and less flexible.

More features do not equal a better product

Build, Review and Refactor

We don’t expect to get it right first time, so we try to get an iteration in front of your users as soon as possible.

Release, get feedback, then go back and iterate again. The advantage of rapidly iterating is that the feedback is truthful and is a more sound basis to develop against. We have also found that people find it difficult to imagine how an application will work without seeing a working version. Humans respond better to real life, rather than a set of imaginary mockups or worse still a long specification document. Getting an application out into the real world gives real world responses.

Release. Listen. Revise. Repeat.

Real World Testing

We place a strong emphasis on real world testing, as the feedback from this is invaluable. Testing done in too formal a manner only gives a partial picture. We have found that allowing users to do real world testing gives much better feedback. We also apply this to the testing we do ourselves during the build phases. It also means that your users see their feedback and opinions being actively taken into account. This has the added benefit of building momentum and motivation with your staff.

Keep Timescales Small

We believe that any estimate over a few weeks is fantasy. You have no idea what is going to happen in the future. As a result we keep timeframes small and manageable. Tasks are broken down into hours, rather than days. Each task is worked on one step at a time. Any problem that is too big, should always be broken down continuously until it is manageable and digestible.

So why do we do this?

Well in our experience programmers are optimists. “That’ll be simple” or “No problem at all” is often the response to a task. Give someone three weeks to do something and generally two weeks will be spent ‘considering’ and 1 week actually ‘doing’. Keeping the timescales small and manageable ensures that programmers are efficient and have a sense of accomplishment as each task is completed.

Define It

The top priority of a project is to define the "core vision" for the application - what is it’s primary purpose? Before anything begins we all have to know what this is. Why are we building it? What is its purpose? What is the products "core vision".

This vision helps us all make decisions and ensure that the project follows a consistent path. If we define your application up front, sticking points can be overcome much more easily by asking "is this true to the vision?"

Ignore Detail Early On

Success comes from paying attention to the small details. But pay attention too early and the results are meetings, disagreement and delays. We believe that the key is to focus on the detail later in the process. Get the application up and running and don’t spend whole days perfecting the small detail. We make sure that perfection comes later, once we have the core of the application working.

The rationale for this approach is that, it is far better to get an application being tested and used, than to be ensuring that the UI is perfect, a font the right size, or a button in the right place on screen.

Often what we thought of the detail becomes entirely different once people start using the application. The real detail emerges from usage.

We always work from large, down to small.

Say No!

Every feature that is added to an application requires a whole set of steps to implement it. So every time you say 'yes' remember you are adopting a child. This adoption process is a time consuming and costly exercise. So before saying 'yes' it is important to make this new feature work hard to become part of the application.

It Just Doesn’t Matter

When building an application, people request many features. But we believe that it should be a priority to consider whether they actually matter or not. Most just don’t. We will always ask if they are really essential, do they really matter? If they don’t we think you should leave them out. The best applications are not the ones that try to answer every possible permutation, they are the ones that can determine which features actually matter or not. By doing this, the productivity on the features critical to the success of the application go through the roof. From experience we have noticed that the most wasted time is spent on feature sets that just do not matter. Cut this out and your application will benefit exponentially.

So how do we go from an idea to releasing something of real value?

Brainstorm

First we establish the ideas. What does this product do? What are the your needs? What needs to be there for the application to be useful? What vision does this product have? What is the core functionality?

Sketch

Next we build quick, cheap and easily talked to sketches. At this stage we are simply trying to get all the ideas out of your head and onto paper. The primary goal is to take the idea out of your head so we can start to create a rough interface.

Prototype

We then use these sketches to build static html / mobile versions of the application. The aim to get something that looks real so that people can talk to it, discuss it and review it. In our experience users respond far better to a real set of screens, rather than long documents. No serious coding yet, just a prototype of your product. Implementation comes afterwards.

Code

When we have a consensus on the prototype, we start coding. Plumbing it in. However we stay flexible. If something turns out to be wrong once the code is in place, we are always prepared to refactor. You should expect multiple iterations of this stage. Code, review, revise and repeat.

Brainstorm, Sketch, Prototype, Code

We develop applications for our clients using an agile project management methodology. However we have added our own enhancements to this methodology. What you see below is a typical two cycle project process from Kick Off to Implementation.

The amount of development phases that you need depends on the complexity of the project.

We feel that our approach has three key benefits:

Flexibility - people need to be able to change their minds, especially during a development cycle. We allow customers the ability to change scope, as this leads to the best end product.

Expectations - we don’t want to build poor quality products. Fixing time, cost and scope is a recipe for poor quality. By focusing on the quality, our clients expectations are met more easily.

Priority - the result of fixing time and cost is that people focus their attention on what is most important. Tough decisions are made, rather than simply being added to the end of an ever increasing scope.

It is better to release a product of the highest quality, on time and on budget, than a product full of scope creep and poor quality.

So many applications are designed code first. We don’t believe that this is a good idea. Code is the biggest overhead for an application and one the hardest things to change once in place. Therefore we start by designing the interface. Sketches and prototypes that are easy to change and review. Customers can see and talk to prototypes. Code, on the other hand, makes this much harder and is much more of an overhead when you come to revise it.

The interface is what the customer sees as the application. Effectively it IS the application. Bad interface design will show through, especially if it has not been factored in right from the start. When we build interface first we have screens to talk to with you. It smooths the process. It is easier to ask questions like, does it make sense? Does it answer the problem? Is it easy to use? Building interface first gets you to those answers sooner in the process.

Many commentators argue that software should be agnostic, saying it would be arrogant for feature requests to be ignored, or to limit features. Software should always be endlessly flexible.

We could not disagree more. We take sides.

We believe that software should have a vision and an opinion, it should never sit in the middle. This opinion should be one of the top priorities. This way the software has an attitude and takes a position that people can clearly see. You will never keep everyone happy all of the time, so the software should not try to sit on the fence. The desire to maintain flexibility creates software with needless preferences, unnecessary features and a dilution of the core message. It also leads to bigger overheads, an increase in bugs and the amount of effort required to support it.

So what is the Advantage of Being a Small Company?

The bigger the company, the harder it is to change direction. We actively want to be a small company so that we can stay flexible, keep up with advances in technology and make big changes, rapidly. We think that we can help companies better by staying lean, by keeping our mass reduced.

We follow the following principles to stay lean:

• Our staff must be able to multi task. No over specialisation. We should all be able to code, design, project manage and meet with our customers.
• All team members must be able to self manage.
• We live with and embrace constraints. We feel that with constraints you have creativity.
• Never over design and keep software code to a minimum. Code is the biggest long term overhead, so keep it simple.
• Keep feature lists down and concise.
• Small team sizes.
• Pare the interface down and remove superfluous complexity.
• Maintain an open culture that allows for mistakes. This way they are found and rectified swiftly.

Keeping to these principles ensures that we can react to change much easier. Evolution becomes possible, bad ideas can quickly be dropped in favour of the good ones. We can listen to customers and respond to their needs. We feel that a technology company that cannot evolve is a dead company.

Keep it tidy, keep it simple