Early on at Codacy we decided that we were going to make something that we would actually use.We would like to think that we drink our own champagne.
By being a developer one could effectively become the first user. When we started developing the first iterations of what now is Codacy, we learned a lot from building a developer centered product.
We built what we would like to see working for us.
And so we went to work on it.
We did very quick cycles to see the product working and shipped to the first users (us).
We did (and do) very few meetings and a lot of demos. Working functioning code is and was the real measure of how we’re doing.
But I can tell you that in the very beginning it definitely didn’t feel like champagne.
Even dog food could be considered a gourmet meal comparing.
So that’s when we decided to turn the process of self-use a blocker. That would mean that before any release is done, Codacy must always be ran against Codacy.
And that’s what we did.
In the process of using our own product there were a few lessons learned:
Process
To make ourselves respect the new rule we decided: no production deploy before Codacy is tested against Codacy.
The lesson here was discipline. Process takes time and agility but creates quality and methodology.
Our future plans regarding this include a more pervasive use of Codacy through our continuous integration servers.
Scratching your own itch
Part of the joy of making something for your team is the challenge in surprising them.
We now challenge each other to make better code by creating patterns for comments that are recurring in our code reviews. In the process of doing this automation we actually developed patterns that were useful for ourselves.
As an example, just yesterday Rodrigo hacked a new code pattern to analyze CSS using CSSLint:
Obligation and User lens
After a while, we actually stopped development for a full couple of days to focus on being full time users.
This meant that we just used the product and acted on every tip Codacy told us.
We of course took note of every small improvement to be made. But more importantly, we saw big structural changes in the product.
We stopped to correct every single issue that Codacy told us. And in the process, the product became better twice.
Not bullet proof
Although this pinpointed major issues, that is not enough.
I believe you implicitly get used to live with some broken windows. I think this happens because you stop questioning everything that is before you.
Furthermore, even taking ownership of what you developed (i.e. you should not be your code), you leave some there implicitly.
So we constantly ask user feedback and we do feedback sessions.
We constantly email our users asking how’s their experience and we take analytics from their use as well.
We also invite developers and designer we respect to hurt our feelings.
Perhaps you start eating your own dog food. Slowly I think it’ll become champagne.
*This is a blog post of our Code Reading Wednesdays from Codacy (http://www.codacy.com): we make code reviews easier and automatic.
Edit: We just published an ebook: “The Ultimate Guide to Code Review” based on a survey of 680+ developers. Enjoy!
About Codacy
Codacy is used by thousands of developers to analyze billions of lines of code every day!
Getting started is easy – and free! Just use your GitHub, Bitbucket or Google account to sign up.
GET STARTED
