I've settled on titling this series the "Weekly Internship Post" or WIP. This week I'll be talking a bit about the driving decisions that dictate software design during development (and dispensing myself a gold star).
I'll first need to give a little background on what Dynasty does. Real estate firms own property with the goal of renting said property for profit. Firms employ real estate agents, who have the job of finding prospects willing to rent said property. Naturally, part of the agent's job is to find these prospects in the first place.
Dynasty provides a software service, Lisa, that converts interested prospects into booked showings for agents.
In the past, these showings, or tours, were always in-person. Due to the current climate, there has been a large push to practice social distancing, so in-person showings don't cut it anymore. Before I joined, Dynasty added an virtual tour option, which is basically a video call where the agent walks around the unit while the prospect stays at home.
In the past two weeks, I've been working to add self-guided tours as an additional way for agents that manage properties with lockboxes to practice social distancing. In this case, the agent would stay home while the prospect gets a code to walk around the unit themselves.
Towards the end of development, My PM and I realized that we've attached the tour type of a showing (in-person, virtual, or self-guided) to the property level instead of the showing level. This means that all showings that we book for a property (think apartment complex) will all be of the same type.
Imagine the situation where an agent would like to use in-person tours normally, but use virtual tours for out-of-state prospects. In the current set up, we would force the agent to choose between only using in-person tours or virtual tours for the property they manage.
Considering the speed at which these new tour types were developed, I wasn't surprised that a mistake like this could be made. I quickly bubbled the issue up to my manager and waited for him to give the green light to pull tour type down to the showing level... except I was informed that the current design is correct!
It was explained to me that most of our clients wouldn't find it useful or wouldn't be able to support multiple tour types. Agents have to learn how to effectively use a new tour type in their routine, and many are normally quite content with their current systems. While there are agents that would like to be able to support multiple tour types, the reality is that most of our customers wouldn't find any value. In fact, giving them the option could be more trouble as they could become overwhelmed with unneeded complexity.
To really drive home the point, I'll go over some other resources that help explain the decision.
Here's a great talk about API surface area that supports this thesis. Tl;dw: Write spaghetti code, and only add to an API if there is a clear pattern in the written code that points to creating new API functionality. The overhead of writing standard, but longer code is lower than the overhead of understanding a complex API.
In this case, our service is a sort of API for agents. For the longest time, our users just needed in-person tours and it worked great. Due to clear demand, we've added two more tour types to the API, and are already dealing with onboarding issues. It is not clear if we need to add even more to the API by allowing different tour types on the showing level. If the demand shows itself over time, we'll support it. Otherwise we're just burdening our users by providing them more options than they need to effectively do their job.
To finish, here's a quote I found while reading this increment article:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. — John Gall
From my prospective, it seemed like a mistake to be unable to support multiple tour types. And indeed, in a vacuum, the chosen design is strictly less flexible. The takeaway for me is that stakeholder concerns are just as important as engineering concerns when building products. At a high level I understood this. But coming from a curriculum focused on instilling sound engineering principles, it was eye opening to see the extent of how stakeholder concerns influenced engineering decisions. Companies build products, not abstract systems. When evaluating future decisions, I'll try to focus more on how it'll impact the end user.