Software Process: A Journey through History

Kopis Mobile's Software Engineering Process Explained

Mechanical pipes

What is a "software process" and do I have/need one? Basically, it's exactly what it sounds like - the process you or your company uses to build, test, and release a piece of software. So whether you're a solo developer working on side projects at home or part of a huge team at a multi-billion dollar business, you're implementing some form of software process whether you realize it or not.

I started working at Kopis Mobile in 2016 and since that time, we have prioritized improving and streamlining our software process. Read on to see our journey though the eras of software processes we've been through at Kopis Mobile, starting with the Dark Ages.

The Dark Ages

Honestly, even the Dark Age would have been an improvement for our software process - we were more like cavemen right after the discovery of fire. We were comfortable with using Git in a team setting. We used a modified Git Flow branching scheme to provide some structure to our Git environments, and that was about the extent of our software process at the time. Everything else was a bit of a mess: deploy keys for Android apps were stored on one person's machine (I think they were backed up on a CD somewhere?), and every artifact we shipped to a customer was built on one developer's machine (there were lots of issues of "works on my machine").

There were six of us on the engineering team at the time, and we were very siloed. For the majority of a project, one developer was responsible for all the new work done. We followed Deadline-Driven Development, where our priorities were set by what project had the closest deadline. It was stressful, hurt morale (even if we may not have recognized it), and we had a bad bus factor.

The Renaissance

For us, the discovery that sparked our Renaissance was Agile and Scrum. But it wasn't an immediate hit. We had several on-and-off attempts at implementing Scrum before really committing to it in late 2017. Many of our "failures" stemmed from the belief that traditional Agile and Scrum didn't work for us. Things like:

  • We had multiple products and contracts we were working on, but only one team
  • Our deliverables were usually contractually obligated, not customer-driven
  • Because of our market, we had limited customer interaction, which made it hard to get feedback and iterate

These challenges almost kept us from realizing the power of Scrum. A lot of our early difficulties revolved around us trying to force our process onto existing tools, which only increased our headaches. We used JIRA for a while because others in the company were using it, but it didn't work for engineering. We migrated to GitLab for our repository and tried using project issues to track features, but that didn't work either.

The common problem was a lack of visibility/support for cross-product teams -- remember, we were a small team working on multiple projects concurrently. So, we went old-school, using a white board and color-coded sticky notes per project. This gave us the cross-project scrum board we needed so badly. And it worked great, until we had a team member leave to work remotely for three months on the other side of the country. Using the physical board as a prototype, we built a digital solution that tied into an OpenProject instance to plan and store features for future work.

While we were determining our tooling issues, we were also figuring out how to make the actual Scrum methodology work for our team. We started with half a day for planning with two and then three-week sprints. We also allotted half a day to share accomplishments with the team and discuss how things went in retrospect. For a while we combined those two half days into one long review/retro/planning day, which we later decided was too much time to spend in the conference room together (the company at least catered lunch on those days).

Age of Exploration

We had finally reached a point where the whole team had an idea of what everyone was working on at any given time and where we were headed. Along with this insight came a conscious desire to break down silos and conduct cross-training where possible. It was uncomfortable at times, but it was definitely the right idea. Encouraging people to work on things they weren't familiar with forced us to learn each other's code and share some of the tribal knowledge that's inherent in a silo'd project.

Another way we improved cross-training and code quality was the introduction of merge reviews. Previously, our process included implementing a feature, testing that feature until satisfied, then merging it into the develop branch. Once we implemented merge reviews, we locked the develop branch and required all merges go through an approval review conducted by another team member prior to completion.

While we would never be fully interchangeable - and that was never the goal - everyone benefitted by having a counterpart on the team involved with their project to bounce ideas off of. Just like the early explorers, we were learning more about our world and the challenges and possibilities it offered.

The Industrial Revolution

As we continued growing, we looked outward to see what other companies were doing and what tools and processes we could adopt. This sparked our Industrial Revolution. Just as the first Industrial Revolution revolved around transitioning from hand-made goods to machine-made ones, our Industrial Revolution involved automating some of the tedious tasks involved in software development. Since we were already using GitLab for our code repository, it made sense that our first major leap came from learning and implementing GitLab's Continuous Integration and Continuous Delivery (CI/CD) pipelines.

Typically, when you run "git push" on your machine, the files are sent up to your repository and that's it - they just sit there. But there exists a way to employ a team of magical robot workers to take the code committed, build an application, run tests, and deploy it to a server or mobile app store of choice. There are many different CI providers out there: CircleCI, Jenkins, Travis CI, etc. But GitLab has a built-in CI/CD solution - even their free tier offers some access to their CI runners that can build and test your code. We host GitLab on-premises, so over time we have developed a fleet of runners to build everything from PIC firmware to Android apps, and everything in between.

This was the one change I believe had the biggest impact on improving our software process as it helped a lot of our Dark Age problems. Software builds had to be reproducible on a runner - no more "but it works on my machine" issues. If it couldn't be built with a clean CI image, it was like it couldn't be built at all. Deploy keys and other secrets are now stored in private variables that only runners have access to when needed. Now the majority of the tedious, repetitive actions are automated away, allowing you to focus on more important tasks.

The Future

Our software process journey is far from over. There are still pain points that we are aware of and others I'm sure we haven't even yet considered. For now, there are two main areas of improvement where we plan to focus - improving automated testing and code quality tooling and better ways to manage code maintenance and technical debt.

Key Takeaways

  1. There are no "one size fits all" solutions to software processes. What works for us may not exactly work for you. You must first determine where you're at, where you're headed, and how you want to get there.
  2. Break down silos - this was one of the most helpful things we did to improve morale.
  3. Invest in automated tooling - there's no reason to stress out over manual build and deploy processes in 2022.
  4. Take time to document, develop, and refine your software process - just like with continuing education, there are always things to learn and improve about your own software process.

For more information about our small, Mississippi-based tech company, visit Kopismobile.com.

About the Author

Richard Sween is the Director of Engineering at Kopis Mobile and is an accomplished engineer with over a decade of experience in user research study, design, and execution as well as Android and OS software development. 

Photo credits -

Mechanical piping photo by Martin Adams on Unsplash

Cavemen image from SpongeBob SquarePants on Nickelodeon

Silo photo by Sebastian Grochowicz on Unsplash

Scrum board photo from Silicon Valley on HBO

Simple

Simple

Intuitively designed for easy navigation

Reliable

Reliable

Stable so you can focus on your job, not your equipment

Rugged

Rugged

Tough to hold up in your austere environments

Secure

Secure

Solid to guard your mission