How much of your Software Design can you do “on the move”?

A fair bit of your Software Design can be done when you are not sitting in front of your machine.

Feb 02, 2024

Quite a bit, actually.

As a Software Developer and Architect, I realize that I need a machine for a number of things. I obviously couldn’t do my job without a computer. Okay, that’s a no-brainer. And before you judge me for stating the obvious, hear me out.

What I am beginning to state is that you don’t really need a machine for a few other things that you would do as a Software Developer or Architect. Sure, you could do those very same things in front of a machine but I’ve actually seen that it can be counterproductive. And here’s my rationale for that argument.

Let’s take one of the things I do as part of my everyday professional life — Software Design. And if you are wondering why I might have to do this on a daily basis as every design is followed by development, my simple answer to you is that there is so much we have to do at Snowpal, hardly a day goes by without a design for that next feature. Long story short, I do a ton of design work. And if I waited to sit in front of my machine before I did each and every one of those designs, it would simply eat up a good amount of my development time and we certainly can’t afford that. That apart, it isn’t the most productive approach either so I can hardly see myself do that.

Diagram was mentally “drawn” during a workout session

3 paragraphs later, let me try and get started with how else do I do it then. Well, here is the approach I’ve taken for a long time and it has worked very well for us. So, you may want to give this a shot too, and let me know how goes.

I document both my initial thought processes about new requirements and the follow-up software design work during my daily walks.
I record them into a series of voice memos on my iPhone and number them.
I then upload them into the respective directories in Dropbox or Box.
I recap the gist of every voice memo in the last 25–30 seconds.

As with everything else in life, it is best to take a simple example and understand the process I called out for (aka, recommended) above.

Say, we are designing a restaurant management application and are beginning to think about the high level requirements. Here is what the first voice memo will likely include:

Voice Memo #1

We need to build a SaaS Web Application that allows an admin user to sign in to view all the restaurants they manage. The first page should show them all restaurants under their purview, let them add a new restaurant and also view the employee roster for each of those restaurants.

At this point, I would stop recording this voice memo (in the real world scenario, the requirement — even the very first one — wouldn’t be this simple so the voice memo would tend to range from 2 to 5 minutes, and sometimes can get as along as 15–20 minutes, so the corresponding transcript wouldn’t be as short as 4 lines long either, but you get the idea).

The next voice memo can aim to take a stab at the underlying APIs that we would need to implement to support these requirements. Now, the API implementation could be based on REST or GraphQL (or something else). But, much like we all have a native tongue that we “think” in before translating to the other languages we may converse in, a lot of us developers also have a native language, framework, library or protocol that we first “think” in. And when it comes to APIs, it’s REST for me. So, even when I am developing Graph APIs, I tend to first think in REST before I convert it to the Graph equivalent. So, having said that, here is how I would think about the APIs.

Voice Memo #2

I would assume the API is public (which it of course wouldn’t be) and not worry about securing it initially. My focus would be on the underlying specification. So, the first thing we need is a list of restaurants, then we need a single restaurant and finally, all employees that work at the restaurant. So, the API list would be something along these lines:

https://localhost:3000/restaurants

https://localhost:3000/restaurants/:id

https://localhost:3000/restaurants/:id/employees

https://localhost:3000/restaurants/:id/employees/:employee_id

That would be it as far as the second voice memo is concerned. Now, the 3rd voice memo would touch a tiny bit on the user interface.

Voice Memo #3

Admin user signs in entering their username and password, or via a Social Media sign in. Once they do, they will see a list of restaurants (be it listed on a grid or as cards, or using one of the most common UI components). They will see the name of the restaurant along with some metadata (like last modified date, etc). When the hover over a restaurant, they will see some actions and one of them would be to list all employees who work at that restaurant. When they pick that action and hit Enter, they will see a list of all employees listed once again in either a grid or as cards (now, the same UI component can be reused to render the employee roster).

With these 3 voice memos, I think we have enough to get started with the implementation work, really. Sure, we can draw the UI so there is a wireframe or a mockup and if these UI pages are so unique and new, we would need to do that. But it’s likely you already have similar pages so you can simply reference those pages or components in the voice memo and you should be good to go.

At this point, we are ready to start coding the APIs and the implementing the UI as well. Which means, when we go to the machine next, we can actually open our favorite editors of choice and hit the ground running!

Now, to be honest with you, there are occasions where I tend to do a bit more in voice memos (like think about file names, class names, dependencies, repo decisions, GitHub issues, checklist items, and yada, yada, yada) but that will take a bit more explaining and I think it would be worth writing about it in a different article.

(Snowpal) Backend as a Service APIs, Apps, Courses, Podcasts

Discussion about this post