John, founder and CEO of Homebase, met with me in the Mission in SF for a burrito soon thereafter. I was impressed with John’s command of the problem he was solving for – helping small businesses with straightforward tools that ultimately give them and their teams more time back to serve their customers. He was very personable, humble and energetic – we clicked right away. We agreed to have me meet with the small founding team in SF. 

I met with the team a few times – both in the office and over a beer at a local pub. I really liked them! After these conversations John and I agreed that this would be a good role for me to jump into. It would be the closest thing to starting something myself, and while the team of maybe ten people had built the go-to-market product, there was a ton of work to do against a real engineering practice that would power the company’s post-seed round future. 

I joined at the end of April 2015 and set about helping the team with anything that needed to be done. Thinking back on that time – we were about ten people, no more than fifteen: John, Rushi, Angela, Evgeniy, David, Eugene, Kai, Andrew, and Greg. I embraced this opportunity, completely bought into John’s vision, and prepared to “make my own mess this time” rather than coming in at a later stage to try to impact someone else’s “mess”!

On day 1 the first problem to tackle was operational stability. The team was developing against a single git repository and releasing to production once a week – Wednesday nights at 7 pm. At this point in time we often either went down right after the production deployment, or the next day when traffic peaks returned. My very first objective was to determine how we were testing the application both with automated tests written by engineers, and verifying them manually. I collected every test list that John and the other team members reviewed, created the first master list of use cases, and built out a testing matrix of all cases that needed to be confirmed before a production candidate could be deployed. I don’t think I’ve ever done as much software testing as I did in my first three months at Homebase. I also developed some simple SQL scripts to run in production that confirmed that the application functioned as expected post-release.

We had also made an initial investment in the concept of unit tests in our Rails application, but had not made the full effort to fix broken tests. Every branch was red all the time. So we pushed to fix the suite and began to rely on it so that when it ran green, we felt safe that no new bugs had been introduced, and started the discipline that when it ran red, we had broken something.

Over time we started to release to production consistently without going down, and I then started to push forward to release more than one time per week. But my ability to test production candidates did not scale, so I set out next to come up with a strategy that would scale.

At Crowdflower I was aware of an interesting SF startup called RainforestQA. As background, Crowdflower built a platform where users could build out a set of tasks that are sent out to crowd workers around the world. Their data is collected and verified for the user. RainforestQA built an interface for teams that need test cases run on their application and these tests can be written in simple language and logic. They were a demanding customer for Crowdflower – I met with their CTO several times to solve challenges for the benefit of the RainforestQA platform. I brought them on board, and along with a member of Homebase Customer Service (Andrew), we created sets of RainforestQA tests that allowed us to much more quickly regress a build candidate.

In a fairly short period of time, we were able to build out a regression suite that stood in place of manual testing which in turn empowered us to move to daily releases, then eventually to three to five releases per day on the web application – turns out this was our first step toward quasi-continuous deployments. Our operational stability improved greatly with small and concise deployments.

The other big event in my first months with the founding team was making my first engineering hire. I thought long and hard about what I needed in this first hire – someone with the courage and curiosity to join an early team, someone with broad skills and the desire to take on whatever needed to be done. There were a few people in my network that came to mind – people I had worked with previously who I knew I could count on. But one person in particular, Jordan, stood out from our time together at Crowdflower. 

Luckily for me, Jordan was up for lunch. We met and I pitched him on the role. Jordan was clear with me – he wanted an opportunity to work on Platform and Infrastructure problems in addition to doing full-stack web feature development. I was excited to offer him this opportunity – we really had little idea of how to tune our AWS infrastructure. Jordan joined in August 2015 and jumped in feet first.

In addition to jumping into the team with his powerful skills, Jordan got into the details of AWS and by the end of the year had figured out how to operate our infrastructure and fine-tune resources to keep our platform running smoothly. His foundational work allowed us to run AWS’s basic tools for the next couple of years with nearly 100% uptime and put almost all of our attention toward building out the feature set. This was critical at a time when we could not afford to hire additional staff.

I remember feeling good toward the end of that first year with the team – our testing strategy was in place, our release cadence had been established, and our operational stability solidified. We were ready to evolve.

The post My Journey to Homebase, and the Earliest Days appeared first on Homebase.

VIPER is a backronym. Something that has to be explained every time you mention it probably is not a good idea. Roughly it translates to: View, interactor, Protocol, Entity and Router.

The ways VIPER was implemented in our system was:

• Views
• Interactors – almost all business logic was encapsulated in this- how components interact within the architecture
• Router – includes methods for all exits, modal launches, or other navigational changes
• Data source – or, API handler, gets data and reloads data, includes all methods for data management including loading. This roughly maps to the E in Entities.
• Assembler – a class to put the entire thing together. Also named “wireframe” at times or “factory”

On the plus side…

One of the key benefits of VIPER– binding views with data elements — was not available in our implementation because we weren’t using Swift and Realm at the time. For complicated forms, this does make the code more sensible, as those tend to go with longer controller classes, with more validations and business logic.

VIPER is very testable, and that was one of the reasons it lasted so long in our codebase. You can easily mock up the data class, ignore the view class, and test the business logic in the interactor, router, and view model. For complicated forms, this was really smart.

On the negative side…

One of our first misgivings was: why so many files? For a given feature, 6 files were a minimum. If there were more view models, screens, or modal screens, this would quickly increase. VIPER was born from the “fat controller” problem. So it does limit the number of code lines in a single class. Perhaps in Swift, this would be easier, but for Objective-C, since you need a header and implementation file, this makes it a problem of files X 12.

What didn’t work out so well was hiring new folks into a codebase that had VIPER architecture. The ramp-up time for a level 2 engineer into VIPER was at best 1-½ months, at worst, 3 months. Our feature delivery velocity was hit almost immediately. With risk management- testing- we improved our codebase, but feature delivery tanked. I explain this as- in the world of Apple development, there have been rarely any new frameworks introduced, unlike JavaScript, where a new framework seems to launch each year. Engineers in this field are very used to MVC, or MVVM. This was a big learning for us- that experimenting in a new framework in a relatively stagnant technology meant we spent a lot of time teaching a technology to folks who were questionable about the merits (rightly so, too).

Since you’re out of the normal MVC that Xcode recommends, accessing a view controller from inside a separate class to do router-like behaviors like ”launch a pop-up” become very complex. Also, get very familiar with delegates and protocols, and objects that are essentially just protocol- something we are finding very difficult to move to Swift.

• Never use VIPER in Objective-C, very wordy and overly complex
• Highly recommend for isolating complex business logic for testing- if MVVM isn’t enough
• Do not recommend for nested architectures, too complex.

Nested VIPERs

One of the major risks to look out for: nested vipers. When one architecture “nests” another model inside of it. This can cause a lot of issues and complexity around referencing a new model, instantiating it, then routing to the specific screen or navigation you need. When you’re doing this two or three deep, the number of files and recursions get complex and buggy. One of our first initiatives when we decided to leave VIPER was to collapse or flatten the nested architectures.

We’ve moved our codebase now to Swift and MVVM, testing view models and models, and limited UI tests. So far, this has helped with training new engineers, and the testing coverage is maintained. We still have a few single-generation VIPER architectures lingering around, either to switch to Swift and keep, or move to MVVM.

The post To VIPER, or Not To VIPER appeared first on Homebase.

I remember taking a call with Jeff Auston, VP of engineering at Homebase, a few days after the Christmas break. I had read about Homebase. The company provides a suite of freemium and subscription based software in support of running a small business: timesheets, schedules, GPS based clock in/out, integration with payroll systems, onboarding, hiring, and more. Homebase makes the lives of owners and employees easier on Web and Mobile platforms. Coincidently, I had spent three years at Amazon working on similar software for fulfillment centres. Homebase’s mission to make the lives of small business owners and employees easier caught my attention. Plus Homebase’s business had doubled year over year before the pandemic, grew 30% during the pandemic, and its data was used by US agencies to understand the effects of the pandemic on small businesses. It was January 6th, a lot was going on in the United States. Jeff started the call by touching base on the events of that day in the United States. A great sign when leaders express their own emotional state with composure. We talked about Toronto as a hub with a combination of leaders and talented engineers coming through professional hires, university channels, and talent migrating to Canada. Toronto is the most multicultural city in North America with tons of talent migrating here every year. I have spent most of my career working for big tech companies and a start up in between but never had an opportunity to help establish a business in its new hub. I told Jeff I was interested to proceed with the interview process and the rest is history! 

Along the interview process and since I joined Homebase at the beginning of March 2021, I have met many great leaders and contributors including the company CEO, John Waldmann. They all present a humble determination to expand the benefits of Homebase to as many small business owners and employees as possible. I am also learning Homebase’s culture of service to customers, no day being wasted, all while having fun! Engineers are expected to deliver to a known average velocity for their level but the velocity allows for a solid work-life balance. The company now employs about 120 diverse employees across the globe. At every show and tell newcomers are to tell the whole team about themselves in a mad lib (a fun way to get to know your colleagues 🙂 ). I have been here for about 6 weeks, I know that challenges and opportunities lie ahead. We have a lot of work to do to achieve our goals, but at this point I can’t be happier with my decision to join Homebase.

The post Why is Homebase’s Toronto Hub My Next Gig? appeared first on Homebase.