I’m going to tell you something I probably shouldn’t, since I’m a developer at a software development company (please don’t fire me Mikel!): In my opinion, the actual code that we give to our clients is one of the least important things that we deliver to our clients.
I’m not saying that code isn’t important, I mean, it’s the thing that your customers and employees will end up using. But there are plenty of contract developers that will charge you by the hour who can deliver a thousand lines of code a day. But how do you know that the code is any good? Does it meet your requirements? Are you getting regular releases to a test environment so you can keep an eye on the progress? You need to have a structured process in place in order to even be able to answer these questions, and that’s what I mean by process being more important than code.
At reinteractive, like many software consulting firms, we have many developers who have worked in many companies (and even countries). As such, we have all experienced a lot of different ways to develop software. Over time, we have coalesced all of our experiences into a standardized process that we apply across all of our projects. This means that when you engage with us to develop your software, you’re buying not only the code, but the tools and practices that we use to verify that the code works, deploy it regularly to the internet, and so on. In this post, I’ll go through the main parts of our process and describe each one and why they benefit both you, and us.
One note before I start, I’m not going to use the word “Agile”. Agile is one of those terms that has been inflated and devalued to the point where nobody actually even knows what it means anymore. So in this post I’ll skip the buzzwords and just describe things in concrete terms.
Managing and Defining Requirements
Often, clients will come to us with a very high-level brief, something like “We need an app to help us manage our clients.” That’s a perfectly valid end result, but you can’t simply will something like that into existence; you need to get there incrementally. At reinteractive, we help you break down the higher-level brief into smaller tasks and arrange them in a logical order, such as allowing users to sign in, sending out confirmation emails, allowing admins to update customer details, etc. By doing this, both you and us are really fleshing out what exactly needs to be done, coming up with a plan of what will be done and in which order.
Most companies will have a preferred tool for this. We use Pivotal, some use Trello, others use Post-It notes on a whiteboard. But it’s the same idea for each: each task gets written into a ticket, and arranged into a backlog. You can then have columns like “To Do”, “In Progress”, “Ready for Test”, and so on, that the team maintains throughout the project.
Just by doing this, we avoid a number of problems that tend to come up during software projects:
- The higher-level end result has been turned into a list of deliverable tasks.
- The developers have defined, concrete tasks that can be worked on. They can just pluck the next ticket from the top of the To Do column and get straight to work.
- Everyone in the team (the client, testers, developers, and managers) can see where each task is at in the development process. You will never need to ask “is this task being worked on?”, or “can I test this yet?”.
- By working on small tasks rather than large ones (think one day rather than a few months), our developers can deliver new features to you daily (or multiple times a week, at least), which you can then view and test, rather than having to wait a few months for the entire project to be done before receiving anything to play with.
- By sorting many small tasks into an ordered backlog, the team is essentially forced to consider the priority of each task. This means critical tasks get dragged to the top, and the superfluous “nice-to-haves” naturally float to the bottom. That doesn’t mean they won’t get done; just that they won’t get done before the critical and high-value tasks. This is especially important if you are on a budget. You don’t want to be wasting time and money on low-value tasks when there are high-value ones still to do.
Regular Meetings and Communication
There’s nothing worse than being out-of-touch with the rest of the team for extended periods. From this, a lot of problems can arise: * Developers might have picked up a lower priority task, unaware that something higher priority has come up. * A developer might have misunderstood the requirement of their task, and be building something that doesn’t meet your needs. * A developer might have deployed something to the test environment, and be waiting for feedback. It’s best to be able to test and provide that feedback while they’ve still got that task fresh in their minds, rather than when they’re halfway through the next task.
On the other hand, it’s possible to over-communicate, to the point where half the day is being spent in meetings. Some clients, particularly bigger clients, have a tendency to have multiple-hour project management meetings, with developers mainly sitting there bored and unproductive the whole time. Every minute spent in a meeting is a minute not working on new features. At reinteractive, we do daily “standup” meetings, which should ideally take no more than 10 minutes. It’s really just a meeting to coordinate what everyone is doing today, rather than raise new requirements or do in-depth scheduling. All that should be done in the ticketing tool described in the previous section. After that morning standup, all members of the team (developers, managers, clients, etc.) then communicate via a chat tool (we use Flowdock, but can also use Slack or anything else that you might prefer). That way we can ask questions, request reviews or testing, and announce deployments. The idea is to find a good balance between everyone being in contact, but not to the point of hindering the rest of the team’s productivity.
Quality Assurance
Automated testing is writing code tests that execute the application and verify that it is working as expected. It is an important part of the software development process that many smaller companies and contractors skip over; often due to time and budget constraints. The rationale is usually “we’ll just get the feature out the door, and then circle back and add tests afterwards”. And then it doesn’t get done. And then the same for the next feature, and the next, until you have a whole app built with no automated testing. There are many problems caused by this, but the big two are:
- This means that when a developer makes a change, to add a new feature or fix a bug, there is risk that the change could break something else. But how will the developer know?
- In order to verify that nothing is broken, every time a change is made, you have to either just accept the risk, or manually test everything. That’s time consuming, and frankly impractical.
Rather than getting stuck in this trap, it’s best to just incorporate testing into your process from day one. That way you never get behind, and you never have to play catch up. We sometimes have clients that come to us exclusively to add a suite of tests to their app, before they do new feature development. This is costly, and avoidable with just a bit of extra work up-front.
To facilitate testing, it is recommended to use a “Continuous Integration” tool, which is just a fancy way of describing a dedicated environment that continually runs the application’s tests, verifying that they are all passing. The alternative is to run them manually, which people will inevitably forget to do, often after the work has been merged and deployed. CI tools ensure that the tests are run, notify the team about any issues, and prevent you from merging or deploying work that breaks the tests. At reinteractive, we use Travis, but there are many others out there.
As well as testing, a simple way to maintain the quality of the development is to mandate that all new code added to the application gets reviewed by at least one other developer. This is normally done by raising a “pull request”, which is really just parking the new work on a separate branch, and only merging it into the main branch once another developer has approved and reviewed it. By having developers cast their eye over each other’s work, any potential bugs are often caught before the work is deployed to the test environment, and knowledge about how new components work is shared around. This is something that most developers intuitively know, but is often sacrificed for the sake of time. At reinteractive, code reviews are a standard part of our process from day one of a project.
Regular Releases
Having an environment in which to test newly-delivered work is critical to the success of the project. Without one, you have no way of knowing if your developers are working at a good pace, or even that they working on the correct tasks. It also allows you to test new features before they get deployed to the main “production” environment where your users are. We call this a “staging” environment. Sadly, many teams neglect to set this up, but at reinteractive, having a staging environment is a standard part of our OpsCare¬Æ service. We make sure that your staging and production environments are identically configured, so there is a place to deploy new features where you can test with confidence that if it works on staging, it will work in production.
Having a staging environment is not much use though, if you don’t do frequent deploys. Many teams get into the bad habit of only deploying once a week, or once a month, or even less. Sometimes it’s due to laziness, but other times due to the deployment process itself being too complex to be worth doing frequently. At reinteractive, we use a “version control” tool which allows us to work on each feature in its own “branch”. This means features can be worked on independently, and integrated together when done (with the “pull requests” described above), making for a stable, cyclical deployment process. This also means that each feature can be deployed the moment it is ready to go, without them needing to be bundled up and deployed in batches. There’s no reason why your team shouldn’t be able to deploy new work to staging at least daily, provided that the team has broken the tickets down into small enough tasks.
Obviously, that’s a desirable thing, but in order for it to be realistic, your team needs a fast, automated system for deploying new work to staging. There are a whole host of tools out there, but at reinteractive, another part of our OpsCare¬Æ package is a set of tools that runs the entire deployment process with one command, meaning that your development teams can deploy the newest version of the app to staging in around 10 minutes. It’s important to keep your process quick and simple; the longer it takes, and the more cumbersome it is, the less your team will be able to deliver new features.
Once your team has got a cyclical, efficient process in place for frequently deploying their work, then they will be able to deliver each feature to the staging environment for testing as soon as it is done, meaning you can test and provide feedback. The faster your team can get into this rhythm, the faster the feedback loop, and the more likely you are to get the product you want.
To tie all this together, I’ll wrap up with an anecdote that should convince you that all of the above is important. Many years ago I briefly worked with a company that had no process at all. The developers were fine, but they didn’t write tests, they didn’t review their work, they didn’t have a test environment, and so on. You can guess what the end result was:
-
Messy code, which slowed down development time; to get anything done a developer would first have to untangle the relevant section of the app to figure out what was happening.
-
Buggy code, not only because of the state of it, but also because tracking down and fixing a bug took so long it often just wasn’t worth doing.
-
Without having code reviews, information was “siloed”, where only one developer had any understanding of how each part of the app worked, since they never reviewed each other’s work. You can imagine what would happen if a developer were to leave.
-
Without tests, there was no confidence that the app was actually working. Every deployment was a risk. While there, I witnessed a deployment to production being rolled-back because someone left a breakpoint in (a “breakpoint” is a development tool that halts execution of the app). You can imagine what that did when deployed to the live servers.
-
Without a test environment, they had no choice but to deploy straight to production and hope that the code that worked on their laptops worked exactly the same on the servers. In order to test on the servers after deployment, they would time their work day so that they could deploy at night-time in Europe, their biggest market. I imagine their US and Asia/Pacific customers weren’t too thrilled about that!
I hope from this example you can see why process is just as important as just hammering out line after line of code. It ensures that you get what you want, of a high quality standard, and in frequent deployments to a test environment. And it doesn’t take too long in terms of time or cost to set up. Really, it’s just a matter of getting your team into good habits and sticking to them. At reinteractive, we will work with you to establish this process from day one so the rest of the project will be smooth, and you will get a high-quality product out of it.
