[Chugalug] OT bugs and code quality

Eric Wolf ebwolf at gmail.com
Fri Mar 14 20:34:00 UTC 2014

At SolidFire for C++ code, before pushing to mainline branch:

100% code reviews
100% unit tested
100% pass on "commit smoke"
Reasonable pass on Coverity
Entire company shames devs who still manage to get crap through (very, very

For Python code:

~90% code reviews
~10% unit tests
100% pass on pylint
Publicly awarded Mr. Hankey the Xmas Poo figurine if you push code that
breaks other people

And these processes feed builds into our formal QA and Automated Regression
test process.

We use Mercurial for code repo because it allows for easy branching and
merging. We use KilnHG because of their web-based code review system.


Eric B. Wolf                           720-334-7734

On Fri, Mar 14, 2014 at 8:45 AM, Ryan Bales <thinkt4nk at gmail.com> wrote:

> tl;dr: A lot of code quality issues are due to carelessness.  If you can
> help your developers rediscover their love for their craft, they'll start
> caring about their work again.
> I've found that fostering a culture of code worship goes a long way toward
> maintaining code quality.  If you're hiring the right people, you're hiring
> people who started writing code because they enjoyed it at some level.
>  Sometimes, though, functional requirements, user stories, morning
> stand-up's, and all of the other devices we've created to direct a
> developer's passion toward serving business goals, all help to dispel the
> notion that our work is a labor of love.
> Everyone knows that fatigued teams make more mistakes.  We often, simply
> chalk this up to too much work, taxed minds.  I think, though, that it has
> more to do with shifts in perceptions of work as a joyful, satisfying
> labor, to work as mere toil.  I don't know about you, but when I don't care
> about what I'm doing, I don't pay attention.
> If you regularly spend time with your team, just worshiping code, admiring
> expressive, beautiful code, and improving faulty or complicated code, I
> think you'll find that your team's code quality will improve.  Sometimes
> I'll review one of our team member's code, other times we'll review some
> rockstar's code on github.  We'll even look at code in different languages,
> as long as everyone is generally familiar with the paradigm (e.g. I
> wouldn't just jump into some Haskell with a PHP team).
> Disclaimer: I've found this works when you have at least one or two
> developers who enjoy what they do and are willing to participate.  If you
> do, the rest of the team will begin to participate over time.  This, of
> course, assumes that you've done a decent job of hiring your dev team.
>  Having had some success with this in the past, I attempted this with a
> team that I adopted in a new position.  The developers were so burned-out
> and disgruntled, that I had little success with this approach.
> So much of our success is dependent upon cultivating a healthy, happy
> culture.
> Ryan Bales
> http://twitter.com/#!/thinkt4nk
> https://github.com/thinkt4nk
> On Fri, Mar 14, 2014 at 8:43 AM, Ed King <chevyiinova at bellsouth.net>wrote:
>> I've seen software written by fortune500 refugees that is just as
>> buggy/unmaintanable as any other stuff I've ever seen, despite all the
>> fancy tools used and money spent
>> bugs are gonna happen, best thing you can do is to keep the complexity
>> down, and hire/keep people who care who can fix the bugs quickly and learn
>> from the mistake
>> if you've got an MVC system that is "7 layers deep"  in abtraction and a
>> framework that only the writer of the framework understands, then you get
>> what you deserve for letting it get that complex
>> I consider myself quiet fortunate to be on a small team (3 programmers
>> and a QA person) who have all been with the company for at least 6 years
>> and we know the system and how it works, and despite getting paid peanuts
>> and no bonuses, we still care about our work, and I really think that keeps
>> a lot of our bugs down
>> plus we're all good lookin,  that helps.
>>   ------------------------------
>>  *From:* Christopher Rimondi <chris.rimondi at gmail.com>
>> *To:* CHUGALUG <chugalug at chugalug.org>
>> *Sent:* Friday, March 14, 2014 9:17 AM
>> *Subject:* [Chugalug] OT bugs and code quality
>> For those of you are on/lead teams of developers or engineers what do you
>> do keep everyone focused on reducing bugs and thinking through the impact
>> of changes? I get there is a lot that can be done with unit and integration
>> testing and formal QA. However, what I am asking centers more on keeping
>> quality front and center in the team's mindset.
>> There is probably no easy answer to this but, how do you separate bugs
>> that are caused from "moving fast/meeting deadlines" versus we probably
>> should have caught this one?
>> --
>> Chris Rimondi | http://twitter.com/crimondi | securitygrit.com
>> _______________________________________________
>> Chugalug mailing list
>> Chugalug at chugalug.org
>> http://chugalug.org/cgi-bin/mailman/listinfo/chugalug
> _______________________________________________
> Chugalug mailing list
> Chugalug at chugalug.org
> http://chugalug.org/cgi-bin/mailman/listinfo/chugalug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://chugalug.org/pipermail/chugalug/attachments/20140314/ec9901a2/attachment.html>

More information about the Chugalug mailing list