What skills do you need for large projects?

Recorded June 12th 2020 – watch the full episode on YouTube.

You've got stack of experience working on very large projects, including VLC, Netflix, and Apple Maps. What techniques do you use so your code lasts longer and is more maintainable in the long term?

Carola Nitz: That actually made me smile because I was thinking like, “oh I'm just deleting everything and writing everything from scratch now." You try to have certain components, right? Make sure that you structure code so that one piece of code has distinct functionality, and you have APIs that are clearly defined so you can easily exchange components. I don't have these big entanglements between code pieces and the better they are defined the easier it's going to be in the future to exchange something old for something new.

"Make sure that you structure code so that one piece of code has distinct functionality, and you have APIs that are clearly defined so you can easily exchange components."

Paul Hudson: And that's critical, right? In fact that's one of the advantages of protocol-oriented programming – we make small components, so that each part does one exact thing. There's no inheritance chain where Samoyed inherits from Dog, which inherits from Animal, which inherits from Mammal, and so on. You just have this sort of flatter hierarchy: bring in this functionality, bring in that functionality, etc. It makes it replaceable – it makes it you can change your mind later.

I think it’s so important because no one in our industry claims they're going to get their code right first time – we pretty much accept we're going to totally screw the first one up. “Plan to throw the first one away,” is actually in a serious book by Fred Brooks about this exact topic. So structuring our code with that in mind means thinking about our dependencies as “can I remove that? Can I change it easily? If not I've got a problem.”

Carola Nitz: Another way to think about this is if you can write good unit tests for your code that's a good sign you structured it well.

Paul Hudson: Right. Presumably that's why you do amazing TDD right Carola?

Carola Nitz: Sure. Honestly we do have really great automation and good test coverage for new features, where it's possible.

Paul Hudson: Another amazing Jon Reid quote is, “good tests give you the confidence to make bold changes to your code." And it's so true – when I've got a project with comprehensive testing I can rip out any code I want and put in a new code, and if passes the tests I'm happy. It doesn't matter what I’ve done because the test guarantee the behavior is the same, and that's the magic of your tests – as long as you've written good tests, of course! It’s another conversation entirely, but having that confidence to change old code is hard, and this is why we end up with COBOL or Fortran code out there that no one dares to touch.

"If you can write good unit tests for your code that's a good sign you structured it well."

Because that code is handling hundreds of millions of dollars a day and you don't dare break it because you would lose your job and you'd be ruined forever. If it had tests, and of course it won't because it's very, very old, but if it did you could take out the old code and put Python in, and it wouldn't really matter – as long of the output is the same you’re safe.

Prathamesh says, "this is really a matter of composition over inheritance." I think that gets to the core because it really is about how you can compose many things into one – a little bit of one thing, a little bit of another, and then rip one out to put a new thing in, as opposed to having a huge class hierarchy. Imagine if Apple took out UIResponder – everything would catch fire!

Sponsor Hacking with Swift and reach the world's largest Swift community!