From inspiration to production, Part 1
This is the first part in the From inspiration to production series.
- From inspiration to production, Part 2
- From inspiration to production, Part 3
- From inspiration to production, Part 4
One year has passed, where are we now?
It has already been over a year ago since I wrote Hitting the sweet spot of inspiration. It seems fitting to follow up with another love-piece about my love for composition. Last time I wrote about the genesis of Spots, the framework that was the result of being inspired. But fear not, I am not a one trick pony, there are more topics to cover than just composition.
A lot has happened since my last piece, both personally and at work, but one thing still remains the same, I’m still equally inspired to push forward. Mainly because we’ve seen such an increase in productivity from building our own abstraction on top of Apple’s UI framework(s). Because of the internal success of Spots, we decided that it should be a part of the teams core foundation, making it a corner stone for any new application that the team works on. We can now build applications faster and more unified than we did two years ago.
Finding your core foundation.
Being a small team, we face the same challenges as any other team. Everything seemed simple on paper but in reality we are met with deadlines, curve ball demands and unforeseen speed bumps. When we were fully booked, it meant that everyone had their own application to focus on. This meant that everyone was conflicted as to how to spend their time. Time spent discussing meant less development time, which led to increased pressure. We were caught in a spiral where collaboration had become secondary. To make matters worse, not everyone could participate in discussions as they had their own meetings to attend. In the mix of it all, we couldn’t wait for everyone to weigh in on discussions that could potentially have a big impact on the team. This left people with a fear of missing out and ultimately left them with a feeling that their opinions didn’t matter, causing friction and unnecessary conflict within the team. This had to be addressed, and fast.
The problem with the real world and services like Slack is that they are synchronous, if you are not along for the start of a conversation you might end up missing the train.
We wanted something that felt natural, that would fit with our day-to-day operations. The solution we came up with was a GitHub repository that we decided to call iOS Foundation. We decided early on that this repository should be public. We thought people could share our collective knowledge, join in on discussions or ultimately do the same for their team. After all, sharing is caring.
One big advantage that we cannot stress enough in retrospect is the ability to have a source of truth for the conclusions of our discussions. You can learn a lot from prior conclusions, even if you don’t agree with them in present tense. Sometimes the path forward is first to retrace what led you to where you are now.
An improved process
By adding Spots to our core foundation, we can safely say that our general development process has become less error prone as it removes the repetitive tasks of hooking up data sources and delegates, something that can easily add minor flaws if you forget those minor details. In short, you reduce the amount of code duplication because you don’t repeat the same implementation over and over again.
With all that clutter gone, we have more time to focus on what makes the applications great. We have more time for UI and Unit tests, as well as working closely with designers making animation timings just perfect.
And last but not least, we have time for what we couldn’t do before, discuss things properly without the need to feel stressed. I could go on and on, when what you save is time, the possibilities feel endless.
Time is a pretty great currency to bank on.
Establishing iOS Foundation and adding conventions to what frameworks we pick helps us reduce the amount of context switching when jumping between client projects. This is crucial if you aim to have a collaborative culture. The incentive to help grows because of the ease of transitioning between implementations. The more alike they are, the easier it is to context switch.
We first feared that the foundation would introduce constraints that would reduce the overall happiness of the team. It does come at a cost: the freedom to pick or jump on anything new. That said, the foundation is not set in stone, it should be a guiding light that should always be questioned, revised and improved, just like your implementations. It should help you to sober up when picking new technologies and introducing new dependencies that affect the entire team. Creating a strong foundation takes time and involves a lot of discussions, you may find that you don’t agree on everything, but I bet you will surprise both you and your team on how many things are already defined as an unspoken rule.
Naturally not everyone will be satisfied with all decisions, here is where democracy comes in. We use the thumbs up / thumbs down to place votes, if there is a majority then things should be settled. With that said, just because something did not get accepted into foundation doesn’t mean that it cannot be used. Core foundation just defines the go to tools, if that tool is not up to par, ask yourself, “can it be improved?”. If yes, then it is a great opportunity to do open source development. If no, maybe we need something completely different. Too many ‘no’s over time should also be a guiding light to if the tool is really for general purpose and belongs in the foundation for the long run.
Foundation ended up being so much more than we originally thought, it is more than just issues. It is our forum for discussing the way forward for the team. Even if the activity on our foundation has slowed down, it doesn’t mean that it doesn’t work. On the contrary, I think it proves the opposite. With friction greatly reduced and having a source of truth for our conclusions, we think that our future selves will find it useful to be able to look up why, how and when we got to where we are. As mentioned earlier, looking at the past can be the best way to advance, but remember, be kind to past choices, even if they ended up being wrong. Instead embrace and congratulate that a choice was made.
We still use Slack as the primary tool for communication but as soon as we get into a discussion that involves making a decision that will affect operations, we tend to move that over to foundation so that everyone can participate when they have time.
Initially I wanted to sum up everything in one article, I quickly saw that I had too much to say in one sitting so I decided to split it up into four parts. This was the first part of From inspiration to production, and don’t worry developers, there will be snippets of code in the upcoming articles.
You can find me on Twitter @zenangst and on GitHub @zenangst.
