Home Developer Champagne Mindset & Software Development

Champagne Mindset & Software Development

Author

Date

Category

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

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Subscribe to our newsletter

To be updated with all the latest news, offers and special announcements.

Recent posts

How does code quality fit into your CI/CD pipeline?

Continuous Integration and Continuous Deployment (CI/CD) are key for organizations wanting to deliver software at scale. CI/CD allows developers to automate...

How Stim uses Codacy to achieve high-quality code

We spoke with Tobias Sjösten, Head of Software Engineering at Stim, about how Codacy helps them guarantee code quality and standardization...

6 things developers should do to ship more secure code

Writing better, more secure source code is fundamental to prevent potential exploits and attacks that could undermine your software applications. However,...

Best practices for security code reviews

In today's interconnected world, where data breaches and cyber threats are increasingly common, one of your top priorities should be to...

April Product Update 🚀

Hi there 👋 It's been a whirlwind month, and we have big news to share: