“Oh no, it is raining” was what I was saying when looking outside of my window after getting out of bed. As I am getting from A to B in Zurich using my bike having bad weather turns out to be even worse as bad weather is already by itself.

Especially on this day, it was raining really a lot so I was wondering what I could do. Zurich (as Switzerland in general) has very good public transport, so maybe instead of using my bike, why not use public transport on this rainy day? Unfortunately it turned out, using public transport was not an option for this day: There was a meeting at my university in the morning, then I planed to have lunch at Google Zurich and right afterwards another two meetings at the university. None of the meeting I could move or cancel. The commute time from university to Google office is significantly longer when using public transport then when using my bike, which for this packed day would mean I couldn’t make it between all the meeting to get to Google, have lunch there, and then make it back to university for the next meetings in time.

Your speed in an environment

So, in a sense, I had to make a trade off: Either I use a “nicer” solution in terms of “fighting the rain” and use public transport, loose the ability to move quickly (in other words, loose speed) OR to just face the heavy rain, be able to move faster with my bike and thereby make it to lunch at Google. I was looking forward to meet my Google lunch partner for nearly two week and so I decided to face the heavy rain.

What are your options when you want to cycle in heavy rain? Right, you need to take on a lot of rain gear, that avoids you from getting wet when cycling through the rain. And that’s what I did in the end: Open up my shelf, take out my full bike rain equipment, put it on (then walking like an astronaut), managed to not get wet this way while riding my bike through the rain and managed to be on time for all meetings and enjoyed amazing lunch communication at Google.

What I found most interesting about this is the following discovery: Your speed (that is, how fast you can move within a given environment) is not only dependent on the environment itself, BUT also on the help, support, tools, gears, … you apply to the environment. This allows you to keep up your “normal speed” - though the environment becomes suboptimal - by investing more into your help materials. Written down in a small formula you get this:

Your Speed = Your Environment & Your Help

By itself I find this formalisation already very interesting. (Holding a Bachelor degree in physics, I just love formulas.) And it gets even much more interesting!

What does the amount of help tell you?

Take for example developing large scale apps (say, you want to build the next Facebook): A common opinion is that for scaling an app and still be able to develop new features at the same speed, you need to have very good tooling that helps developers. That is why big companies like Google, Facebook etc. invest pretty heavily in their infrastructure - the daily developer “help” so to speak - to still make good progress and develop new features quickly (have a high speed) when the developers move in this “big app” environment.

From this it seems, the only way to keep up your speed is to invest more and more into your help / support area. But maybe that doesn’t have to be true always. You can ask the following (maybe provocative) question:

Is there a way you can change your environment instead?

Just accept the amount of help you need?

In a sense, if you loose speed as your application grows, maybe you should not take that as a “yeah, that’s what happens if your app gets bigger” attitude but say instead: As your app grows you must make sure you have the right environment setup to solve the problem. There is a blurry line here between where does changing the environment end and where does the help you provide start. However, what I realised over the last few weeks is, that often when you start using a lot of “help” to solve a problem, it is actually a strong indication that something might be wrong with the environment you try to solve a problem in and instead of throwing more and more support, tools, … at the problem, it might make sense to look at the environment and “fix” the problem there instead.

Noticing that there is an issue with the environment at first place is often hard and not obvious. But looking at the more concrete fact of how much help you need to get a job done is what I find much easier. From this concrete knowledge it seems possible to derive than something about the more implicit healthiness of the environment you work with in.

Now, for sure, you can not always change your environment - in the case of the bad weather, there is little you can do ^^ But over the last few weeks I appliedBut if I see how much tooling there is required to build performant web apps, I started to wonder if there is a way to fix the environment instead.

---

$ #date(07 June 2015)
[Iteration\ Fixed a lot of small typos - thanks a lot to a lovely, wonderful person in Berlin]