It started simple; I wrote Barista as a remote, personal render farm that all Blender users could afford. 

The development journey brought me countless surprises. Now, a year after its release, I am here to share my insight into the development process; how it failed at times, and how it evolved into something greater in the end. 

Lesson 1: Build to solve a problem

A few years ago, while in a CG Cookie workshop, I found myself with a project that would take weeks to render - but my deadline was much sooner than that.

This was a real problem. Luckily, I’m a developer who built systems around AWS and I knew I could remedy the issue. 

Thanks to the Brenda scripts written by a passing acquaintance, James Yohan, I was able to make the rendering process much faster. A few minutes later, I had 8 instances rendering my scene and finishing 20 minutes later - instead of weeks!

While this method worked great for me, others who yearned for the same power, found the scripts to be incredibly hard to understand. It was at this moment I decided to put 3D on the proverbial back-burner, and dedicate all of my free time to turning my solution into a usable product. The product eventually became Barista.

Lesson learned: If you’re building a product that solves a real problem, you’re more likely to succeed. 

Lesson 2: Make sure people understand what your application or add-on does

When I started developing Barista, I was creating it as a tool for myself. This meant that it was very technical and incredibly confusing to non-developers new to AWS. 

This is a problem any developer will run into at some point in their life, and could make for a good explanation why many open-source applications don’t achieve wide-spread adoption.

Because Barista was a tight-lipped secret until its release, there was a lack of an outside opinion of how it could be better. To remedy this, feedback has since been continuously collected from users, allowing an understanding of behaviour, use, and common pain points.

Lesson learned: Don’t limit your market building to a single demographic. Make sure anyone can understand and use your product. 

Lesson 3: Simplify or suffer burnout

One of the biggest challenges of being a solo developer for a multi-layered project was this: how can I maintain the entire project and add new features without spending all of my time making updates? 

Early on, I did updates in my spare time, but this was so exhausting I would end up burning out multiple times.

I tried to limit the time I spent working and mostly work on sweeping patch updates only. However, these didn’t address all the issues that needed updating - so I ended up working more on future updates and refactors. 

All of this meant that I needed to change my approach.

Image credit: medium.com

I learned to manage my time wisely; working on direct updates as well writing new unit tests to keep issues from resurfacing. With continuous integration, this method ensured that Barista was tested with every single change made. Adding linting and type checking eliminated the majority of human error, so the margin of error became incredibly slim. 

Lesson learned: Simplify your development process, and integrate rigorous testing to reduce maintenance and remove repeating issues. 

Lesson 4: All Feedback is Good Feedback

When you are a developer who has used AWS in development since its first release, it’s easy to forget how challenging AWS can be for first-time users.

For that reason, getting to a point where Barista had an easy UX was tough; it took heaps of user feedback, both good and bad. 

But listening to feedback was the only way I was finally able to understand the issues users were having with Barista’s UI/UX. 

Image credit: xd.adobe.com

Still to this day, I value any amount of feedback I can get for anything I write, just like with digital art, the most growth comes from the critique you receive, and Barista has not been any different. 

Lesson learned: Positive feedback is nice but it doesn’t push you. Being open to negative feedback and implementing changes is crucial if you want to improve.

Lesson 5: Write down your mission statement

When I first started writing Barista, I wanted to make sure I never strayed from the original idea, so I made sure to write a mission statement of sorts with a few different goals. As you read this, you may find parallels in the development progress, and I will always suggest you do anything similar for any product you create:

“Barista will always offer a low cost render solution, supporting all artists, and giving it’s users direct access to the AWS Service without additional costs.”

Lesson learned: Writing down a mission statement helps you stay on course amidst the chaos of updates, bug fixes and new features.

Lesson 6: Decide who you are building for

Originally, Barista was written to do a single job: offer an affordable remote rendering solution.

But once I released Barista, I was inundated with feature requests: GPU rendering, custom builds, add-ons, in-app settings for samples, scenes, cameras and more. 

While some of these were features you wouldn’t find on any render-farm, I decided to add them anyway - because I truly wanted Barista to fit every artist. 

Sure, there are always requests that wouldn’t add to the app, or are on the horizon; but oftentimes, a user would reach out and explain that with a certain feature, Barista could completely replace their current workflow. 

I made Barista to benefit the Blender community, which is why users are everything when it comes to its development. If there is a feature request which can benefit the community, or there is an issue that is being mentioned by multiple people, then I will always take the time to at least look into it. Just like with feedback, users want your product to be better, so it’s important to listen to and engage with your users.

Today, I see every feature request as worth considering and I decided that any render related feature request gets added to the list.

Lesson learned: Decide who you are building for and listen to their needs.

Lesson 7: Keep It Simple, Stupid

Once it came to new users learning how to use Barista, I wrote a large documentation file covering every aspect of Barista. While this document was helpful for some, at first it wasn’t very obvious (to me), that the documentation was bloated, dry, and inadvertently pushing some users away. 

I also made a few videos to help people get started with the AWS sign-up process, and the process of rendering. These were helpful to people who were overwhelmed with my documentation and in hindsight, not once did a support ticket come in about the AWS sign-up process, or how the render process worked. The issue was that there were requests for everything else in the app. 

It wasn’t until recently that I started offering the documentation directly within Barista, using those dry docs for reference to specific features and their limitations. 

But there was another underlying problem, Barista just wasn’t intuitive at all. 

To remedy this, I did three things: 

1. added frontend elements like tooltips, event-locked areas, and dialog messages
2. included step-by-step how-to articles for the most common tasks
3. added custom error messages with blurbs on what to do next. 

Adding all of these allowed Barista to cater to a whole new demographic of users: one who needed more hand-holding. 

Now, Barista’s UI/UX helps push these users forward to what they need to do next.

Lesson learned: Users want to install and use your product, but if they are hopelessly pushing buttons, they will get frustrated and won’t come back. Guide them through the process and make the learning phase as painless as possible.

Conclusion

Developing a new Blender service - especially one that is completely original - is a convoluted process. Having a clear roadmap in form or a mission statement certainly helps, as does staying humble and learning from your users. 

I’d be interested to hear if you’ve had similar experiences as a developer!