04 Apr How we helped a Silicon Valley startup reach its KPIs before the deadline
This will be a case study perhaps a bit different than the ones you’re used to reading. Instead of having a company share its successes, this time our success will be told from the perspective of someone who was there through the whole process. Me.
I am a senior developer, working at BDIT for years, and this is a story of how I was out-staffed to help a San Francisco-based start-up company fix issues and reach its KPIs before the deadline.
An overview:
| Project duration: | 6 Months |
| Industry: | Office management and work process automation |
| Technology: | iOS app |
| Project goal: | Fixing bugs and increasing the code coverage from 2% to 25% by the end of the year |
| Challenges: | Time crunch and code complexity |
| Results: | Code coverage increased to over 25% before December |
| Technologies and tools used on the project |
|
Who did we help?
We can’t really mention any names, however, we wanted to at least share the industry: a start-up company working in the area of office management and work process automation.
I worked with them previously, a couple of years ago, on an iOS app that is great for hybrid and remote workers, while at the same time offering many important options for people who work from the office every day. It offered all-in-one solutions for both visitor and employee registration, coordinated work schedules, desk booking, allocating conference rooms, delivery handling, invitations management, etc.
This startup also helped ease work and visitations during the pandemic, as it accounted for vaccine certifications, workplace safety, health compliance protocols, and other useful innovations within the mobile app.
What was my task and how did I approach it?
Getting Familiar with the Code
When they gave BDIT a call and asked if we had someone who is willing to jump in quickly and go through all the code, I was a clear choice. As someone who already worked on the app in question, it didn’t take long for me to step in and start combing through the code.
One of the bigger challenges was figuring out why some bugs were showing up sometimes, and not the other times. I had to carefully go through every line of code that was fairly large and of a high level of complexity, including some of the client’s original tech designs. I knew that only once I understood everything, I could create proper tests.
“I knew that only once I understood everything,
I could create proper tests.”
Trying out a Third-party App
After getting started, I was tasked with testing a third-party app to see if it could help with testing. It took about 3 weeks or so before the company and I agreed that it won’t really work out between them and the third-party app.
It’s easy to take a look at this and think of it as wasted time, however – I don’t see it like that. First of all, we were now aware of the limitations of such an app. And second, we came to the conclusion that even though using a third-party app will help when you’re on a tight schedule, creating your own solution will always allow for more flexibility and fine-tuning to what you need.
Ad Hoc situations are a normal thing in the life of a software engineer, so I wasn’t discouraged and was sure we will be able to reach our targets on time.
What did our coworking look like?
I’d like to mention that, even though I already worked with this company, the process of adjustment to a different team works pretty similarly every time.
The most important thing is to agree on the time when you’ll overlap with the team you’re working with. It’s quite a difference between us and San Francisco, so we established some later hours for me and early hours for them so that we have time to go over everything in a meeting.
Yes, e-mails and messages can be effective–but calls and meetings add speed and remove space for miscommunication.
“The Time difference has this great benefit: getting things done while the team is sleeping, and getting tasks/tickets prepared for me as I clock in in the morning. This helped us move fast, and gave the impression of working on the project 24/7.”
The result we achieved:
| Goals | Results |
| Development speed | |
| Participate in the development of new features based on existing graphic and tech designs and create related tests in order to help speed up the development of the app updates. | Through our participation in development and our work on the implementation of the new features, the team was able to move faster. |
| Increase test coverage | |
| An increase in test coverage by implementing the missing unit, integration, and UI tests. | We were able to successfully add missing unit tests and fix the issues with some of their internal components making existing UI tests reliable. As a result, overall coverage was brought above the initial threshold set by the client. We went above 25% before the end of the 2 quarters we were given as the deadline. |
| Improved build times | |
| Figure out the causes for the overall lack of speed and reliability of the CI builds and fix the failing builds by increasing the build times. Increased test reliability had to be achieved by identifying and updating outdated tests, removing obsolete tests, and fixing the flaky ones. Also, additional test suites (along with the existing ones) had to be taken into consideration. | After fixing the issues with the internal components and updating the build scripts, tests could be parallelized (run concurrently) which increased GitHub Action build times. |
| Monitoring test coverage | |
| To efficiently increase test coverage, we were to add additional monitoring tools at the CI level. | Improved coverage monitoring on the repository level was achieved by integrating the Codecov into GitHub Action scripts. |
Why did this company even need an outstaffed developer?
The answer to that is simple: time crunch and a need for someone experienced and quick to adjust.
The team I worked with was made up of wonderful, smart, senior developers. However, the project deadline was short and they were short on people who could jump right in.
That’s where we, BDIT, and I came into the picture.
I already knew the app, what the company was all about, and have years of experience.
They, in return, knew I was fast, quick to adjust, reliable, and can solve the issues they needed solving.
Who is the author?
Dušan is a senior developer with a lot of years in the industry under his belt. He has been a part of BDIT for many years and worked on various projects with a number of clients. He is someone the BDIT team is happy to learn from, and someone we know we can count on to bring his best game whenever he’s needed.
A happy senior developer, a happy BDIT.
Are you thinking about team scale-up?
If you’re reading this case study and thinking: “I could really use something like this!” – you might be in need of an outstaffed developer (or maybe a whole team of experts?).