While recently designing an API for our Share the Load project, I asked Ben why we were writing some of our methods without adding any functionality to them.
Ben explained that it’s good practice to define what methods you might need before diving straight into writing code that will compile. He likened it to building a house in that “you wouldn’t start a house by laying the bricks, you’d start with the blueprints.”
This really helped me understand what it was we were trying to achieve and it resonated quite a lot. I explained that with all my previous work I had definitely dived straight in to writing compilable code as that is what feels most natural.
I’ve provided an example below of a method we were working on called ‘userDidAnswerQuestion()’ which as you can see has a number of error messages due to missing parameter’s or methods that were not even in scope at the time.
My eyes did not like seeing all these errors! 😬
It reminded me of a conversation we had when we first started working on the project a few months before where Ben got out a physical whiteboard and started squiggling down some logic to figure out some very high level functionality of what we wanted the quiz to do.
At the time I must admit, I was a little confused as to why we were writing it down on a whiteboard rather than writing things in Xcode!
I’ve always been keen on getting to the build and have not needed to spend much thought on the design or structure of the code, and so this way of working was new to me.
As you can see from the photo of the whiteboard we have declared some protocols and the names of the methods that their delegates will require, without declaring any compilable code.
Similar to how we designed the API, what this allows us to do is to visualise and logically go through step-by-step what functionality our quiz needs.
At first it felt unintuitive to be working this way around, and in fact I did need a few more conversations with Ben to help me understand why we were doing it this way. However, it started to make sense once I got to the mindset that the implementation should only be started once the API is finished.
One of the benefits of working this way around is that once the tough part of defining the API has been done the implementation should then be a lot easier as you already have the core understanding of what the app needs to do.
Once you’re happy with the API the next steps are to start fleshing out the methods that you have defined with compilable code and logic.
By starting off white boarding I’ve found that you will be left with a much cleaner API for you, and any other future developers (or future you!) to use.
