Imagine you’re an employee on Toyota’s car assembly line. You observe thousands of micro-movements each second, converging together to perform a systematic technological dance that results in a brand new car.
You notice something’s not quite right. An error in the production line means that faulty parts are being transferred to the next stage. You can pull a special cord to stop the assembly line and alert a specialist team. All eyes in the factory will immediately fall on you. Every second production is halted will cost the company thousands of dollars. Do you pull the cord?
In his timeless book, The Design of Everyday Things, Don Norman praises Toyota’s approach to errors. Instead of punishing errors, the company encourages reporting—pulling the cord and investigating the root cause of a problem is welcomed.
Norman takes the onus away from humans when it comes to errors. Between 75 and 95 percent of industrial accidents are caused by human error. How is it, he asks, that so many people are incompetent? His answer:
“They aren’t. It’s a design problem.”
When problems arise, it’s tempting to attribute them to human error and carry on as usual. We did that at Mobile Jazz for some time. Then, one of our engineers saw the bigger picture. He saw a design problem—and pulled the cord.
Anarchy
Jose Luis Franconetti is an iOS and Android engineer here at Mobile Jazz. He’s worked on a range of challenging projects such as Worldreader—a reading app for offline, low-end devices in developing countries—and MyMoments—an image editing app to help people with mental health problems express themselves.
Other than the hundreds of cat gifs being shared on Slack, he observed a couple of problems:
- The teams developed multiple projects across different platforms at the same time
- Engineers worked with numerous tech leads
- Each tech lead applied their own rules and styles
- Engineers working within these parameters then applied their own rules and styles
Let’s drill down into these further:
Problem One
Different tech leads applied different approaches to their projects. Each person had their own opinion on the best way to manage and carry out development. The process for building a standard feature with one tech lead, for example, varied from that of another.
Engineers can only do so much shape shifting before it gets exhausting. Dropping a particular working style for another requires a mindset switch, which even for versatile engineers can be tiring and time-consuming.
Problem Two
Not only were there different development approaches to contend with, but also different platforms. This meant using distinct frameworks and library preferences depending on the platform.
This had a ripple effect through the mobile team; if one person uses more than one library for networking, well—you’d better do the same.
Problem Three
Our mobile team engineers used different languages. Engineers: set your code switching toggle to overdrive.
Problem Four
Some engineers started new projects while maintaining ongoing projects. Which, combined with problems 1-3, is a bit like trying to wire a circuit board while learning Kafka at the same time.
And a visual representation of the chaos:
In summary, the problems created complete anarchy. Complex switching between projects and platforms, difficulty maintaining the code in different projects, headaches when onboarding new engineers to the company, and the company as a whole delivering projects of fluctuating quality.
In short: a pain in the ass for everyone involved.
That’s when Jose pulled the cord.
Change Required
Only, the cord didn’t halt production. It just sort of slowed it down a bit. Enough for Jose to sit down with the team and explain the problem. Here’s Jose:
“As with any big change, at the beginning there was resistance. I had to talk with the team several times, explaining the issues with real examples from projects we were working on.”
He evangelized to his colleagues about a crazy new way of doing things.
No more Android team.
No more iOS team.
Just one, unified mobile team.
They started to wonder whether this raving engineer could actually be onto something. Then their eyes widened as they realized the possibilities and started asking questions:
- What if we abstracted the development process?
- What if we developed for different platforms using the same patterns?
- What if we used the same libraries across different platforms?
- What if we went to Barbados for our next team retreat?
OK, that last one was a bit of a long shot. But the team were genuinely excited about the first three questions.
Rebuilding
They got to it.
The new mobile team built core open source projects and introduced clean architecture. Then, they set about tackling those key questions.
Abstracting the Development Process
The team did this by creating two different frameworks for iOS and Android. In this case, though, the two frameworks used the same design concepts, functions, and methods for developing applications.
No longer would Mobile Jazz engineers need to switch mindset when changing platforms—applications for both could be built in the same way.
Developing in Different Platforms Using the Same Patterns
The mobile team started following a software model known as Clean Architecture. Other varieties are available—such as Hexagonal Architecture.
Using the Same Libraries across Different Platforms
One more problem to smash through. The mobile team knew it wasn’t possible to use the same libraries across different platforms. Many libraries are language-specific (Java for Android, Objective-C for iOS).
But instead of moping around, they took action anyway. They created new libraries compatible with both platforms:
- Vastra, for validating objects: Android and iOS
- KnockKnock, for simple reachability: Android and iOS
- Motis, and Objective-C JSON mapping library: iOS
- CachelO, a simple caching system to persist objects: Android
- Colloc, collaborative localizations for iOS and Android using Google Docs: PHP
- Hermod, an AFNetworking wrapper: Cocoa
Unity
Just like a “getting stuff done” movie montage, all this looks quite simple in a 5-minute blog read. But the entire process took two years, and required every single member of the mobile team to change their mindset.
Has it been worth it? Absolutely. The turbo-charged mobile team can now switch projects easily, develop faster, and onboard new engineers more efficiently. More money in the bank, faster growth for the company.
Not bad for one humble engineer who recognized the design was all wrong—and pulled that cord.
Got a project for our mobile team? Get in touch.
This post was edited by Steve Howe.
Thank You!
Get Notified On New Articles
You can unsubscribe any time
if you change your mind.
By submitting your information
you agree to our Privacy Policy.
