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!): I believe 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 tangible result of the work we are paid to deliver. It is the thing that your customers and employees ultimately use.
If it is only about the quantity of code, there are plenty of contract developers that will charge you by the hour and deliver a thousand lines of code a day. But how do you know that the code is any good? Does it meet your requirements? Does it do what you intended in a test environment so you have some certainty it is moving in the right direction?
What I have found is that you must have a structured process in place in order to evaluate and eventually answer these questions. 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 multiple companies and countries. 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 are buying not only the code we hand over at the end of the project, but also the tools and standardised practices we utilise to verify that the code works.
In this post, I'll go through the main parts of our process, and describe each one in concrete terms, minus any buzzwords and explain why they are beneficial to both you as the client and us as developers.
Managing and defining requirements
Often, clients will only provide 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 unfortunately we can't simply will something like that into existence; it takes incremental steps achieve the final result.
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 to customers, or allowing admins to update customer details. By doing this, we vigorously flesh out exactly what needs to be done, coming up with a plan of what will be done, and in what order of priority
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 arrange the tasks into columns like "To Do", "In Progress", "Ready for Test", and so on, which the team maintains throughout the project.
Just by doing this, we avoid a number of problems that tend to plague software projects. Advantages include:
- 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 daily (or multiple times a week, at least), which you can view and test. Compare this to waiting a few months for the entire project to be done before you get to review anything.
- 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 waste time and money on low-value tasks when you still have high-value tasks remaining to be done.
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:
- A developer might have picked up a lower priority task, unaware that something higher priority has come up.
- A developer might have misunderstood the requirements 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 to your developer while that task is still fresh in their minds, rather than when they are halfway through the next task.
On the other hand, it's also possible to over-communicate to the point where half the day is being spent in meetings. Some clients have a tendency to hold multiple-hour project management meetings, with developers mainly 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) then communicate via a chat tool to 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. We use Flowdock, but we can also use Slack or anything else you might prefer.
Automated testing is writing code tests that execute the application and verify that it is working as expected. It's an important part of the software development process that many smaller companies and contractors skip over; often due to time and budget constraints. Their 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 pattern for the next feature, and the next, until you have an app built with no automated testing. There are many problems caused by this, but the big two are:
- 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 if there are no tests in place?
- 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 entirely avoidable with just a bit of extra work up-front.
To facilitate testing, we recommend using "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 other tools 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 reviewed and approved it.
By having developers cast their eye over each other's work, 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.
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, knowing that if it works in 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 (using the "pull requests" described above). This makes for a stable, cyclical deployment process. This also means that each feature can be deployed the moment it is ready to go, without needing them 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, deploying daily is a desirable goal, but in order for it to be realised, your team needs a fast, automated system for deploying new work to staging. There are a whole host of tools out there, but another inclusion in our OpsCare® package is a set of tools that runs the entire deployment process with one command. This means your development teams can deploy the newest version of the app to staging in around 10 minutes.
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.
It is 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.
To tie all this together, I'll wrap up with an anecdote that hopefully convinces you why all of the above is so important.
Many years ago I briefly worked with a company that had no process in place 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 had left in a breakpoint. 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 in place, 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 the best part is it doesn't take too much 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, ensuring a smooth project delivery and that the code we give you at the end is both high quality and exactly what you asked for.
Receiving and processing inbound emails with Action Mailbox an...
Simple CSS Dark Theming for Accessibility
How structure and process are the most important things we del...
reinteractive is Australia’s largest dedicated Ruby on Rails development company. We don’t cut corners and we know what we are doing.
We are an organisation made up of amazing individuals and we take pride in our team. We are 100% remote work enabling us to choose the best talent no matter which part of the country they live in. reinteractive is dedicated to making it a great place for any developer to work.
Webinars are our online portal for tips, tricks and lessons learned in everything we do. Make the most of this free resource to help you become a better developer.
The Ruby on Rails Installfest includes a full setup of your development environment and step-by-step instructions on how to build your first app hosted on Heroku. Over 1,800 attendees to date and counting.
The Ruby on Rails Development Hub is a monthly event where you will get the chance to spend time with our team and others in the community to improve and hone your Ruby on Rails skills.