Our Approach to Software Development

Continuous Deployment and Common Sense

We follow an iterative, common-sense approach that borrows from the agile methodology. In practice, development progresses through a sequence of overlapping cycles – while one feature is developed, tested and deployed, further features are being explored, researched and estimated.

Illustration for E-accent's approach, step 1: exploration

01.Exploration

When you first approach us, we’ll be happy to discuss the project at a high level free of charge.

This gives us an idea of what you need, and shows you how it will be to work with us.

What information do we need?

There are three things we need to know.

1. Scope

  • What does the software need to do?
  • What do you want to achieve, in business terms?
  • What existing software does the software need to work with?
  • Are we replacing an existing solution, or creating something new?

"We need a stock-control solution for our existing ecommerce website. It needs to interface with our online ordering system."

2. Timescale

Is there a deadline when the software (or certain features) has to be ready?

"We need the system to be operational within six months."

3. Budget

Is there an overall budget?

"This tool represents a value of $ 125,000 to our organization. We believe that $ 80,000 would be a reasonable budget."

Can we give you a price at this stage?

Estimates always too inaccurate in the planning stage to be useful. What we can do, is give you example budgets of similar projects we’ve completed in the past. A better way to set a budget is to establish what the feature or application to be built is worth to the organization.

Read Step 02. Research
Illustration for E-accent's approach, step 2: research

02.Research

At this stage, we analyse the workflows that will be handled by our software and develop a specification in as much detail as possible.

What do our specifications cover?

Most of our software has to work alongside, or replace, existing software, or a combination of both. Some elements deal with existing workflows (things you can already do), while others support completely new workflows (things you want to be able to do).

As a first step, we’ll identify:

  • new workflows for which no software is yet in place
  • existing workflows that need new or redesigned software
  • workflows that are already well served by existing software.

New ideas and issues inevitably emerge during development, sometimes because of developments in your business over time. To deal with this sort of development, we use an organic approach based on the Agile methodology, which emphasises finding the right sequence of work to let the architecture and design unfold.

"The essence, in all cases of unfolding, is common sense. You want to make a house. At each moment, you ask yourself, What is the most important thing I have to do next, which will have the best effect on the life of the house? Then you do it."

Christopher Alexander, The Nature of Order. Book Two: The Process of Creating Life

How do we charge for research?

Research is charged retrospectively on an ad-hoc basis, using an hourly rate.

Can you review our progress?

We work in Trello, a well-known project management platform, and you will have a login that you can use to view the progress we’ve made. We’ll also send you regular progress reports. You can call a halt at any time, for any reason, and only pay for the time spent to date, or set an overall cost limit in advance.

You can write your own specification. Can you use that?

If you have your own in-house technical analysts, they may be able to produce their own specification, which we will be happy to use if it has the right level of detail. We can also work in partnership with your analysts, if you prefer.

Read Step 03. Estimating
Illustration for E-accent's approach, step 3: estimating

03.Estimating

Once the specification is agreed, we’ll draw up an agreement for the project.

What do our prices cover?

Our agreements are usually fairly simple and include the following elements:

  • for well-established workflows, a description of the concrete requirements;
  • for new workflows, a list of ideas (that may change later on);
  • project milestones
  • a budget, broken down by:
    • milestone and/or calendar month, and
    • role (researcher, UI designer, system architect, developer), costed by hourly rate x number of hours;
  • general terms regarding time of payment, acceptance testing, transfer of ownership and so on.

Can we work within a set budget?

If you have an overall budget, we’ll advise you what can realistically be achieved within it, and make sure that we deliver working software at that point.

We never compromise on coding standards, but if budget is limited, we may have to reduce the scope or the number of iterations that we can commit to optimizing the user experience.

"There's never enough to go around. Not enough time. Not enough money. Not enough people. That's a good thing."

37signals, Getting Real

Read Step 04. Production
Illustration for E-accent's approach, step 4: production

04.Production

We build your software feature by feature, working against the specification and keeping you updated on all our progress.

Will we show you anything before we start work?

We usually do not build wireframes or static (Photoshop) visuals, because we think they are too abstract. Instead, we usually build HTML prototypes to give you an idea of what the final product looks and behaves like. Next, we use the Ruby on Rails framework to build working software as quickly as possible.

"[When one] starts making the real thing, one tends to reach agreement."

Christopher Alexander, Contrasting Concepts of Harmony in Architecture: The 1982 Debate Between Christopher Alexander and Peter Eisenman

How will we keep you in the loop?

The development process is fully transparent, and based on an ongoing conversation between us and you.

We use Trello to manage projects during development. The Trello board for your project will show you exactly where we are in terms of research, coding, testing, and deployment. We will also regularly report progress to you by phone.

If anything threatens the timescale or budget we’ve agreed, we’ll raise it with you as soon as we can and discuss the options in terms of reprioritising or reducing scope.

Read Step 05: Testing
Illustration for E-accent's approach, step 5: testing

05.Testing

We carry out automated and manual testing of features and interfaces throughout development, always aiming for the right balance between rigour, time and cost.

What sorts of testing do we do?

We carry out two types of testing: automated and manual. We build automated tests for every important feature of our software. We also carry out our own manual testing, and expect clients to do their own user-acceptance tests before deployment.

Tests are planned at the same time as features, during the research phase. When we write the specification and use case for a feature, the business rules governing the operation of that feature form the basis for developing tests.

In addition, all our code is peer-reviewed in-house by another developer to make sure it’s clean, elegantly structured and economical. We like our code to be as close to natural language as possible. We use real-world terms, or ‘domain language’, whenever we can.

How much do we test?

Our testing philosophy is ‘just enough’. In other words, we test enough to address all the major risks, but not so much that testing overshadows development, or slows it down.

To decide how much to test, we look at each feature and assess its criticality. If the feature relates to money, for example, or if it’s so complex that important problems could easily be missed, we write an automated test in parallel with the actual code.

Why don’t we write an automated test for everything?

There is a school of thought that tests should be written to explore every conceivable scenario for every individual feature. But we’ve found, through experience, that this approach is time-consuming, wasteful and expensive.

It’s time-consuming because writing tests just takes a long time, and it’s wasteful because clients usually want to change features after they’re built – which means discarding part of both the main code and the relevant test code. As a result, the project ends up slower and more expensive.

We believe our approach offers the best balance of quality, time and cost.

"Be humble about what tests can achieve. Tests don’t improve quality: developers do."

James O Coplien, Why Most Unit Testing is Waste

"Every line of code you write has a cost. It takes time to write it, it takes time to update it, and it takes time to read and understand it. Thus it follows that the benefit derived must be greater than the cost to make it. In the case of over-testing, that’s by definition not the case."

David Heinemeier Hansson, Testing like the TSA

How does our automated testing work?

We use a process of continuous integration. Our testing suite runs constantly in the background as we work, automatically testing each feature following every change made by our developers. This keeps the code clean and manageable, ensuring there are no surprises later on.

How do we approach user-acceptance testing?

Clients usually test several times: usually after we finish an individual feature, after completing a correction and before a set of features goes into production.

Testing complex features can sometimes be time-consuming – setting up data, logging in as a user, logging in as an administrator and so on. If that is the case, we also produce brief demo screencasts showing our own user tests being conducted. These allow clients to review progress quickly and easily without the hassle of carrying out lengthy tests themselves.

Read Step 06. Deployment
Illustration for E-accent's approach, step 6: deployment

06.Deployment

Our approach to deployment is designed to ensure new features go live as smoothly and seamlessly as possible.

We host all sites in development on a staging server, where clients can use the software before it is deployed.

Our staging server uses a recent copy of the data from the production server, so new features can be seen working with almost real-time data.

If possible, we prefer that clients test important features in detail themselves before they go live. This is because clients are usually best at taking the user’s perspective.

Once everything is in line with clients’ expectations, we push the changes to the production server and the new features go live.

We use a completely automated deployment process to carry out the whole update with a single command and no interruption or downtime. We also use detailed checklists to ensure the process runs smoothly and no preventable mistakes are made.