Pivot Produce
A multitenant farmers market
The intent of the Pivot is to take a fully functional single-tenant shopping app and transform it into multitenant site. It'd be like taking Prospect Goods and turning it into Etsy.
It's an exercise in inheriting legacy code, using what you can to make development time efficient and building a new app on the foundation that has already been laid.
The Team
I served as Team Lead and worked with three talented developers over two weeks to build and deploy Pivot Produce.
Emily Dowdle
Jason Pilz
Justin Pease
John Slota
Challenges
The greatest challenge of Pivot Produce was project management. But the challenge took two forms: interpersonal conflict and brownfield web development.
Interpersonal Conflict
I learned valuable lessons in management and collaboration during the first week of the Pivot.
My years as a content management consultant engrained in me the importance of front-loading work to make room for unexpected obstacles, changes in deliverables or extensions to the original project scope. My motto is: "Always ahead; never behind."
I've always recognized intellectually that not everyone has my same work style, but the Pivot forced me to confront that fact head-on.
John and I had conflict from the start. I interpreted his relaxed and care-free nature for lack of work ethic and focus. The bottom line was I didn't trust him to deliver quality work on time. But with the deadline quickly approaching, I had no choice.
So I let it go. I stopped worrying about failing the project and started investing time into caring about my team. We took hour lunch breaks and walked to Starbucks in the afternoon.
Instead of setting strict assignments specific to user stories, I assigned work by general theme. One person handled the shopping cart. Another built out the CRUD functionality for store admins. Another worked on permissions for platform admins.
This style of project management allowed work to be completed in parallel and permitted each developer to take some creative license in the breadth of his or her work, while preventing massive merge conflicts.
As we got to know each other personally, the project turned itself around. I was wrong about John. He is relaxed, but not because he doesn't care. That's just him. It's different from me.
That's OK. In fact, it's better.
We were a better team because John was there to crack jokes and goof off. And I'm a better developer for having worked with him.
Diversity in teams can be frustrating at times, but it's critical to success. Different backgrounds, educations and experiences can create a cacophony of noise at the start. The chaos is deceptive. Because once a team finds it's common tune, there's no stopping it.
Brownfield Web Development
I now understand why it's called brownfield.
Inheriting someone else's code is difficult, even if the code is written beautifully. The Pivot showcased the importance of reading code as well as writing it.
And it turns out reading code is harder than it seems.
None of us had ever created a multitenant app and it took awhile for us to recognize what code we could use and what we would have to scrap.
I fear the delete key. It feels so permanent. But it turns out, deleting code is sometimes the best decision. After all, I'm a developer. I can rewrite it if I have to, right?
Once we stopped tiptoeing around, we found a rhythm. We made mistakes but we fixed them. The mistakes are what taught us the most important lessons.
The Work
TDd + Workflow
As with all my work, the PivotProduce team used tests to drive development. With 226 assertions, our test suite included unit tests, integration tests and end-to-end tests. SimpleCov gave PivotProduce a coverage rating of over 96 percent.
Waffle served as our project management tool. We created user stories as a team, assigned cards and named each git branch based on the card it completed.
PRESENTATION
We used Materialize as a base for the styling and added custom CSS where it was necessitated.
Authorization
The most complex aspect of the project was the multitenancy. There were three types of users:
- Platform Administrators: Site managers who could access anything. Platform admins were the only users capable of approving or declining proposed stores.
- Store Administrators: Store owners or managers who had unlimited access to their store, but not other stores. These users could add, edit and delete items as well as update the status of an order.
- Users: Registered site visitors who could view items from any store, add items to the cart, place orders and view past orders.
Permissions
We used authorization to permit access to pages rather than deny access. The Forwardable module in the PermissionService class provided the ability to permit access based on a user's role.
And if/else statements within the views determined which navbar options a viewer would be presented with. This ensured a user would never experience a redirect after clicking on a link that would lead him or her to a restricted page.
Business Functionality
Pivot Produce wouldn't be worth much if users couldn't shop and purchase goods. Every time a user added an item to the cart, the number of items displayed in the navbar would automatically update. When viewing the cart, users could make last-minute changes before making a purchase.
The multitenant aspect of Pivot Produce allowed for users to make purchases from multiple stores.
From the users perspective, all items purchased were displayed as one order. But store owners were only notified of items purchased from their store, not the items purchased from other stores in the same order.
