The Software Development Process at App’n’roll
This article is the first in my new role of CTO at App’n’roll, a venture builder that creates, designs and promotes web and mobile apps.
Our software development process characteristics are determined by the fact that we can deliver whole products, including but not limited to UX and marketing. Not all products developed within the company are like this but let for now I’d like to focus on this kind, as they are mostly aligned with the process I want to describe and share.
Under such conditions, predictable estimations are essential. We use tools that help us to integrate, keeping the development phase smooth and lowering the risk of unexpected failures. I’m going to describe them from a technical perspective, not only answering what we use but also how and why.
Small teams, big dreams.
For development, we use GitHub repos and as we value transparency, our clients have access to them. This way we adapt some principles of Agile, which inspires our process, however we don’t follow it rigorously so the theoretical rules don’t overshadow the coding fun and the product itself.
You might believe that an eclectic work methodology can create some tooling mismatches and management troubles but it works surprisingly well for us!
We develop our projects in small teams and the advantage of this is that we can follow directly from what inspires us, without the side effects of worsened communication and the large cost of change. This way, we can balance between Trello and JIRA according to the predicted size of the project, without any worries that the team will need time to switch.
For example, if a project manager suspects that using Harvest instead of Toggl will provide us with better reports, the switch for a small team has low transactional costs. We moved form Toggl to Harvest for this exact reason.
Now let’s consider some tools we use all the time. Chrome’s Lighthouse is a really powerful one. Running it should definitely be a standard for every web app. The basic setup gives us performance, best practices and accessibility reports. For those who want the page to run offline there is also a check on PWA support.
There’s even a lighthouse viewer that makes this data an accessible report, even for non-technical project managers and clients. Having the results high is a quite inter-subjective measure for the app’s quality. Although, I assume you might not be a newcomer to technology if you’re reading this, so let’s have a look into more proficient tools.
We never know when our clients will reach the point that immediate scaling will be needed. Therefore, we prepare for it using scalable tools for server infrastructure. Amazon Web Services (AWS) is the best solution here. When we use the cloud we have a warranty to keep the uptime at least 99.97% while horizontal (in terms of the number of machines) or vertical (in machine power) scaling is easy to apply.
As developers who like to work with good quality code that is reusable and easy to refactor we strongly believe in testing. “Saving time” on not writing tests is not an option. It’s a false alternative: write code or write a test for it. The misconception comes from observing software development in the short run. App’n’roll have a great post on code review guidelines on their blog.
We carefully consider each project individually.
From the perspective of our clients and when considering our projects, it’s always better to invest in code quality as tests make the code maintainable and less error prone. Restraining the urge to impress the client with immediately delivered functionalities pays off as the development will be more predictable in the long run.
When we estimate we don’t separate unit or integration tests as they are included in the standard. Although setting up and implementing an end to end testing environment should be estimated separately. We always recommend it because it saves time in terms of discovering bugs and the overall Quality Assurance phase.
What I think we’re missing in our process is more extensive A/B testing. Improved use of this would be of great benefit, as supporting new versions with real analytic data helps to truly develop something better in future.
It’s not only a measuring tool for the client, it’s also fantastic to be able to deliver feedback to the design and development teams, to show that their work is of value and has improved UX which can be clearly seen in the data analysis (unfortunately we can’t apply this to every project, note that this makes sense only in the late phases after release or maintenance mode when the app has enough traffic).
Besides, knowing that some changes made the app worse might be painful but it doesn’t mean the work wasn’t needed. Discovering obstacles or wrong ways is a part of delivering excellent products, which are better than other products in non obvious ways, in terms of performance or having a useful feature instead of not having one. What I’m trying to say is that turning a bug into a feature is often a great thing. It’s all about learning from mistakes!
The process
Firstly, from the clients perspective we have the following process:
- Client call with project manager / first contact form
- NDA, if necessary
- Estimation
- Deal signing
- Development / Design / QA
The last point is conducted in a close loop with client so the product best matches the expectations. We’re not afraid to change the requirements during the development phase, as the details we discover during this process may change a lot and we also understand that ideas evolve during the implementation phase.
Secondly, from a technical point of view, to sum up or just to mention for the bigger picture we use:
- Git Flow
- Management
- JIRA / Trello
- Slack with GitHub and CI integrations
3. Continuous Integration tools which combine:
- Jenkins / CircleCI / Travis / Bitrise
- Unit testing
- E2E testing
- Deployment (sandbox / rollout, staging, production)
- Code Quality Tools
- Linters
- Prettier
- Automated code review tools
- Code coverage analysis tools
4. Monitoring
- Keymetrics
- Datadog
5. Error reporting
- New Relic
- Sentry
- Instabug
- Crashlytics
6. Security
- eg. Helmet.js for node.js apps
- Snyk reports
Not all of the points I’ve mentioned above are used in every project, but that’s the usual setup.
As you can see the subject of a development process is big enough to write a book on, so let me finish here with an honest disclosure of all the points I haven’t yet described. Hopefully this list can bring some value to your projects too.
We’d love to hear from you
If you’re interested in hiring an epic development team, drop us an email (hello@appnroll.com) so that we can schedule a call.
If you’ve been inspired by our process, let us know! Please feel free to share your experiences with us in the comments below or via social media (send us some photos or videos too), you can find us on Facebook, Twitter, Instagram, Behance and Pinterest, let’s connect!
To learn more about App’n’roll, take a look at out our website and our other posts.
