On a project of mine, I started off returning a C# object from a Web API that only had properties like string or int in it. I wanted it to be as small as possible and only return data that was necessary. Unfortunately, as the application continued to be built my team and I realized that we had similar data that needed to be returned in different api’s. For example, we had address data in multiple api’s.
This wasn’t an issue at first until the devs had different names for the same properties. This affected our front end as well when we discovered a bug. A dropdown was empty. So I fixed it by renaming the variable it was looking for. Then I wondered why it broke in the first place. It was an Angular directive that was used in multiple places, but I know it worked when I implemented it. The TFS history showed that another dev changed the variable name it was looking for.
After a quick chat we realized that we needed to create a standardized naming convention for the variable that ran through the application all the way to the C# class. As we stopped and looked at the application we could see that this needed to be done in multiple places. Some of the features were already complete so we couldn’t change them because the deadline was too tight. I decided to create an address object that we could all use. So I added it to my api and I was all set to go. But that did not solve the problem of the other api’s that could have used that class.
I added it to an existing api that I needed to call for a new feature. Instead of rewriting the api and the old feature to use the new class, I just added it to the bottom of the properties in the return object. I did not know if that was a good idea, but I created TFS work items for the future so we could go back and do it the new way.
Then a new project with an even tighter deadline came up that needed those api’s. A new developer for that project asked me which address to use. The one in the address object or the properties. My answer and story for what to do and how it happened did not please him. The look on his face said everything. My idea failed.
Lessons learned:
Looking back I could have done a few things better. I could have versioned the api to a new that only had the address object and slowly move the rest of the app to use that api. Future developers could see it was the latest version and use that instead without confusion.
I could have looked at the whole project before we started and see that the address object was going to be used in multiple places. I could have then created the address object ahead of time preventing this from happening.
I hope my experience and lessons learned can help others build better software.
