5 Things You Must Do Before Advocating Your Reinvented Wheel

You’ve been working for months on your new Database abstraction for Android called Katabase (it’s a library written in Kotlin, so it has to start with a K or you’ll be murdered in your sleep!).

You’d looked into community standards like Room, Storio, or SQLDelight but they really didn’t feel right for you’re project.

Which is great! Have some fun, make something new, be creative!

A few months later you get permission to open source it. Congrats! This could be a great portfolio piece, a great interview discussion, something other devs could learn from.

Maybe it’s so fantastic you can give conference talks about it, or it becomes the new gold standard in your development community.

You begin on your new Medium article, all about your new library and how amazing it is. About how it is BETTER.

But not-so-fast… before you begin publicly advocating use of your framework/library instead of the existing popular solutions, you have a few professional obligations.

Become an Domain Expert

You don’t want to look silly and not be able to answer questions.

Even more importantly, you need to make sure your thing is GOOD in some objective-ish manner.

You may discover something already exists, with an existing developer base, and instead of pushing your SQL abstraction library, you can instead create issues and Pull-Requests to add the missing to features to an existing solution.

Seek out experts in the field for discussions. You may have a Skype conversation with a leading expert, and find a fatal flaw in your library that you need to fix before release. You might learn there is a performance reason or a common requirement which stopped other developers from building the same thing.

Reference Prior Arts

After you’ve done your research, you should reference work that was one previously, and existing solutions.

Link to them in your GitHub README, reference them in your documentation.

It will help users with a starting mental model, and it will also show you respect and appreciate all the work that was done to enable you to build the thing you did.

When you talk about prior arts, you should not just discuss issues with that solution.

Be honest!

Talk about pros and cons, and make sure you don’t paint you’re solution with a dishonest brush.

Most technical solutions are subjective and contextual. Provide that context to your users.

Seek Criticism and Contributions

Open source is awesome.

Developer creativity is awesome.

Creating new approaches and libraries is fun!

But if you are going to say “Devs should start using this in production! We should all switch to my solution, instead of the industry standard!”, you really need to do all the un-sexy work that comes along with that.

That means:

• Accepting contributions (including bug tracking and issues, pull requests, feature discussions) in a meaningful way.
• Don’t just accept criticism, but SEEK it. Ask people what could be improved, talk to existing solution maintainers, ask what pieces of the API are confusing or limiting.

Comprehensive Tests and Docs

Comprehensive test coverage and at least minimal documentation.

It’s not fun.

It’s not sexy.

There’s not much to say here that isn’t obvious.. just do it (if it isn’t done already).

Consider the Industry and Community

Developers and any Industry at large can benefit greatly from large, open-source industry-standard solutions.

It makes hiring easy.

It means developers can speak the same language, and communicate easily.

It means that developers can add features, fix bugs, enhance performance,all at an incredible rate, because there are a few industry solutions instead of 20 different standards.

Often this just can’t happen, for a variety of reasons.

But when it does (good examples in the Android space are Dagger 2 and RxJava) it can be INCREDIBLE for developers, and the many companies and professionals which use these tools.

You should really evaluate (and get evaluation) on your solution before attempting to “splinter the community”.

Having industry-standard popular solutions makes it easier new developers to get into the industry, an area I’m very passionate about.

If a new developer right out of college submits a coding assignment using my small, most-likely worse Katabase library, they may not get the job. Instead of the engineering manager saying “Great. They already understand X, which we spend a lot of time working with.”

Sum-Up

I’m not trying to say don’t build stuff.

Please, build stuff.

Try new approaches.

Be creative and have fun.

People build great things all the time, and new standards are created. And that’s exciting!

But be thoughtful when re-inventing the wheel and then advocating that your new wheel should replace the current one.