David Carvalho
Aug 24, 2017 · 5 min read

A Call for Cross Platform Developers

Intro

When I look at our industry, I see two main and, up to a point, contradictory approaches to team organisation. From one perspective we tend to promote specialisation, which improves the development speed and improves code quality. From another perspective the Lean theories say that we should look at the product as a whole regardless of the technologies used in it and always develop the features that bring more value.

Inside the Hurricane

I have fallen victim to a certain lack of specialisation in the past. I would switch products (not just technology or project in the same product, I’m talking about entirely different products) maybe every 6 months. I would go from working in iOS, to Android, to C back to Android, then some Back-End in Java, back to C again and then iOS once more. Not to mention a few stints at Web Development.

I was good at picking up new technologies quickly, maybe that was why I would frequently be called to projects to “lend a hand”. But in the end, with all the switching of both technologies and products, I felt like I wasn’t actually good at anything nor did I had a reasonable knowledge of each product I worked on.

This caused a lot of burn out. Not only did I had to constantly learn new technologies or to at least catch up with what had changed since the last time I had touched a technology, the huge delay in getting started with a project meant that I would only be able to start delivering valuable features after a reasonable amount of time.

There were several reasons why this was not a sustainable situation, both for me on a professional level, but also for the projects:

· I had to catch up with changes done to the technology (I dread of thinking if Swift had been released back then);

· I had to relearn new best practices or even architecture changes that had been introduced or done during my absence in the project;

· I had to forget bad habits I may have caught from the other project/technology I had been working on;

· It would take me quite a while to be able to contribute fully to the new project since I had to be made aware of why some choices had been made (some choices may have seemed odd, but maybe there was a good reason for them. I had to learn all those reasons from scratch so I would stop making some suggestions that were done before and already discarded);

· In general, although some high level knowledge is valid across projects, I felt like I wasn’t mastering anything, except the art of jumping around random projects and give a hand at putting an out of control project back on track.

I should note that the projects were all extremely interesting and challenging on themselves and I would be happy to have stayed with one of them, get some real business knowledge and to help determine the best technological solution for that project. Unfortunately that wasn’t possible.

In the end the situation simply wasn’t good enough for me. I wanted to gain in depth knowledge of the technologies I was working with but I wasn’t getting very far.

Sunnier Days

Eventually I got to a situation in which I was finally able to focus not only in one technology but also in just one product. Those were some pretty great years; I was able to focus 100% on iOS development.

The amount of knowledge I gained on the different APIs, from Core Data to CoreAnimation, was incredible to me, maybe because I had spent so long without going into those kind of details, the whole experience was eye opening.

I finally spent enough time on a project to realise first hand why MVC could become a problem, I marvelled at the fact that when using CoreGraphics you’re interacting with the model layer and I planned and replaced architectures as I saw necessary.

Our coding practices improved, dependency injection became paramount to our projects and we started doing real Continuous Integration.

Of course during this time I cared about the REST APIs, but not about how the back end was coded. I cared about consistency between platforms when it came to Android, but not so much about how Android was coded or even if iOS and Android could deliver features in roughly the same amount of time.

I don’t think I can emphasise enough how easy it is to fall into this kind of trap, when you’re creating something that works, you see it evolve and improve, you see the small architecture decisions you made bare fruits, the decisions you didn’t made come back to bite you, you gain a certain tunnel vision that is very hard to get out of. After all what you’re doing is working fine, potentially you’re delivering features faster than anyone else

Optimising Value

But that is a pretty narrow view of things. The question you should be asking at this point is not if you’re being as fast as you can, but if the team is being as fast as it can. If a developer completes its part of a story, but the story is still waiting for other developers to finish their parts, then the story won’t be completed no matter how fast the first developer was able to finish its part.

In fact, it doesn’t even matter if the developer is the fastest developer in the world, if the team can’t keep up, the stories will always be delivered at the speed of the slowest developer.

I believe that as a society we have often exalted specialisation and at some level individualism. Adam Smith defended specialisation as paramount to progress. But if you think about it from the automobile industry point of view for example (no wonder the lean theories became more popular with Toyota), if a part of the factory is excellent at producing tyres, up to the point of being the fastest one in the world, but the rest of the factory can’t produce the rest of the car to go with those tyres, then you’re just pilling up stock that won’t be used and by the time it will be used maybe a new rubber type will make those tyres obsolete.

At that point it is better to stand back and think how you can optimise the whole factory so that you can produce cars and tyres when you need them.

Software development isn’t very far from this. You can have several endpoints on your back-end ready to be used, but if the apps or website aren’t advancing fast enough to use those endpoints, all you got is a whole lot of dead code that you have to maintain.

But What’s Your Point?

I’m not sure, I think I have made up my idea about what is the best for a team, but I don’t know how to get there. I started this article with the slim hope it would help me get there, but I’m not sure if it helped.

I do think we need a paradigm shift; if a company wants to stay competitive and deliver the most valuable features to its users as fast as possible, this needs to happen.

I have been observing how teams work and wondering what would be the best way to motivate teams to embrace this way of working, but I haven’t been able to come up with anything close to a solution yet, but I also think I only started to scratch the surface of this matter…

)
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade