Don't optimize your data model prematurely

I wanted to share a lesson I learned recently while working on Atlassian JIRA. The big feature that we’re working on is ability to rename users.

You’ll be able to change a username and it will work, the user will still have the same permissions, all references to it will be kept and world will not fall apart.

You’d think that it should be a no brainer and why I’m even talking about it.

But if you’ve ever seen JIRA massive API you’d notice one thing. Each username (class User) is referenced everywhere by it’s name.

And that’s the lesson I learned. Someone many years ago decided that we have this User (class) but it’s unique key is username (BTW it had also id, but username is so more developer friendly) so let’s not force developers to pass User everywhere, let’s simplify, decrease memory consumption, make things a nanosecond faster and use username everywhere in each API method.

And they did. Everywhere - low level or high level APIs were using username instead of this User class. And the API grew by those years.

So lesson learned, if you have some model objects that are basic for your system like - User, Group, Project, etc. you should never optimize the API to take only a part of it. I know you want to be smart, you want to optimize and the username is so unique that it will never change.

But remember about folks using this software 10 years from now (yup) they may want to change the uniqueness constraint. Make our job easier. Thanks in advance! :-)

It’s not that I’m saying you should be thinking about future cases and trying to predict them. Further from true, I’m saying that you should create interfaces that are light and easy to refactor. In this case taking out a single property out of User and making it dominant violates this.