Building software as a way to learn

How do you keep motivated building things that are thrown away?

Let's be honest: everything we build — cars, houses, and even software — is meant to be eventually thrown away. That's why recycling is so important.

The question is why do we keep building them nevertheless?

Our daily job is to help Mozilla make the web a safe place for users and prevent their privacy from being compromised.

One way of doing so is to build software that empowers people to freely use the Internet while keeping them in charge of their own data.

When users give their data to big companies, they don't necessarily know that they are giving them too much power. As a result, these companies are offering services that respond people's needs, triggering an addictive behaviour which leads to an increase in product consumption. Which lead people to give away even more information about them.

We alone cannot compete with companies that are spending millions of dollars building great products to capture users.

What we can do instead is to build software that, on the one hand, is useful for the Mozilla mission and enables us to fix Mozilla issues quickly while building Firefox and, on the other hand, empowers developers to build their own great software where users can choose where they want to store and control their data.

What matters the most is the vision that this software carries. Without it, is like buiding on sand.

Sure, writing lines of code is cheap and fast. You can build a prototype in two weeks and iterate until you are happy with the Minimum Viable Product.

Note that, it might not be so cheap anymore when you start adding documentation and maintenance costs.

However, the product might be used, and might get some traction for months or even years but it will be eventually forgotten in a git repository somewhere forever.

Writing software to solve problems is not enough to keep motivated on the long term. One needs a greater goal than just writing code.

Having said that, how can one still be motivated on building things that are eventually to be thrown away?

Different people or communities might have different guiding questions.

For our team of developers the secret for solving this problem is actually the following question: As well as solving the problem, what can we learn while building this solution that can be useful for us and for our community to help us go faster and build more robust software later?

For Mozilla the question is: How do I improve Firefox so that people want to use it as their main browser?

By answering these two questions, we define our goals; and we fulfil these goals through software development.

Mozilla is calling this the True North, we are calling it a vision, some other people might call it a utopia.

In both cases that vision should set the route of our ambition and point out a direction for everyone in the team to sail to.

How do you set course for a vision?

OKRs are a way to organise the vision in steps and to move it forward.

To be able to define OKRs from your vision, you need to be able to find the fastest way to get closer to your aim. However what we can learn from sailing is that the fastest way is rarely the shortest.

At Mozilla, we have a vision that is written down in the Mozilla Manifesto, Mitchell Baker does a great job making sure everyone stays aligned with it.

However agreeing on the fastest way and turning the Mozilla vision into OKRs is really challenging. Even more when you have a thousand people's opinion about it.

The idea is to find the smallest and ambitious enough step for which you can mesure the success in the timeframe you set to yourself.

It's the board's job to set course every six months (or even less) on what we should be focusing on for the next six months.

However each manager have to cut down the board objectives in something that their team can have an action on.

When the focus changes, it often means changing our course and killing projects or at least putting them on the side if teams are turning to new priorities.

How do you define your priorities?

At our team level, we are driven by the use case. We have a vision of what we want to build. That leads to feature ideas that we add to the backlog.

However we are not building anything until we have a proper use case for it. As soon as we have a use case it is added to our quarterly roadmap.

We end up not spending time on tasks we don't need and for each use case we are getting closer to our goal even if it might not be the way we'd taken initially.

We also don't have to support code that we don't use. We even remove features that are not used any more.

Our secret is opensource

More than writing lines of code, we are researching solutions to complex problems at scale and turning those solutions into production ready experiments. And sometimes those experiments fail.

The advantage we have at Mozilla, is that everything we do is published as Free, Libre, Opensource Software, which means that, even if, as Mozilla employees, we focus on something else, the work we've done is still available for the community to care about it.

Thunderbird is an example of this. Mozilla stopped spending resources on it in July 2012 but five years later Mozilla Thunderbird is still actively used by a large number of users every day.

When building software, we solve complex issues and all the solutions we have put together are really useful for other people who might need to solve similar problems.

For instance, Mozilla Persona lead the ground for Firefox Accounts and the Portier project, the Firefox Hello loop server shows a good example of how to build a WebRTC signaling server and was reused later by Project Link. The Remote Service Worker project also shows how to use Python asyncio to handle a large pool of websockets using redis to route messages between them.

These are all valuable even though they are not in production anymore today.

Building software as a way to learn

As you can see, every effort is not pointless because we learn a great deal from all these projects.

Whether it takes us a month or a year to build something, we are learning. And if you want to make the most value of this learning, it is important to share it as well.

Luckily, there are at least one kind of people that you already have to inform about what you are doing and learning about as part of your job: your colleagues.

You need to:

• explain what you are trying to solve.
• find out how to solve the issue and agree on the solutions you are putting together.
• take feedback to be able to choose the best solution even before having written a single line of code.

In a next article we will see how we make sharing the core of the process of building software as a distributed team.

In the meantime, we can only encourage you to write about what you are building, go to conferences and tell others about what you learned and listen to them so that you don't have to go through the same pitfall.

Conclusion

In conclusion, don't build software to build software, build it to solve people's problems. Set a long term goal, work toward that goal and iterate. Do not be afraid of killing things that don't work.

In the meantime, make the process of building software a way to learn new things and share what you've learn. Then you don't have to worry about your project being decommissioned because you've already got the take aways of building it.

Make the process of building software a way to share what you've learned and enjoy it!