OT bugs and code quality

From: Christopher Rimondi 
------------------------------------------------------
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

=============================================================== From: AverageSecurityGuy ------------------------------------------------------ A lot of the =93we should have caught this=94 bugs can be eliminated by = using good frameworks. Build your own if you have to. SQLi and XSS are = solved problems with the right library and a militant enforcement of = using the library EVERY TIME. Buffer overflows are also a solved problem = if using the correct methods in the language of your choice.=20 Are there particular bugs you are worried about? -- Stephen Haywood Owner, ASG Consulting CISSP, OSCP 423.305.3700 asgconsulting.co On Mar 14, 2014, at 9:17 AM, Christopher Rimondi = wrote: 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.=20 that are caused from "moving fast/meeting deadlines" versus we probably = should have caught this one?

=============================================================== From: Ed King ------------------------------------------------------ I've seen software written by fortune500 refugees that is just as buggy/unm= aintanable as any other stuff I've ever seen, despite all the fancy tools u= sed and money spent=0A=0Abugs are gonna happen, best thing you can do is to= keep the complexity down, and hire/keep people who care who can fix the bu= gs quickly and learn from the mistake=A0=A0=A0 =A0=A0 =0A=0Aif you've got a= n MVC system that is "7 layers deep"=A0 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=0A=0AI consider myself quiet fortunate to = be on a small team (3 programmers and a QA person) who have all been with t= he company for at least 6 years and we know the system and how it works, an= d 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=0A=0Aplus we're all = good lookin,=A0 that helps.=0A=0A=0A=0A=0A

=============================================================== From: AverageSecurityGuy ------------------------------------------------------ a framework that only the writer of the framework understands, then you = get what you deserve for letting it get that complex I didn=92t mean a framework like Drupal, Django, or Rails. I meant a = simple library that does all the input validation/sanitization and = parameterized SQL queries. 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 This is by far the best way to keep bugs out of your system. Correlation !=3D Causation. :) -- Stephen Haywood Owner, ASG Consulting CISSP, OSCP 423.305.3700 asgconsulting.co buggy/unmaintanable as any other stuff I've ever seen, despite all the = fancy tools used and money spent down, and hire/keep people who care who can fix the bugs quickly and = learn from the mistake =20 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.=20 that are caused from "moving fast/meeting deadlines" versus we probably = should have caught this one?

=============================================================== From: Ryan Bales ------------------------------------------------------ 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

=============================================================== From: flushy@flushy.net ------------------------------------------------------ This is what we do: * Static code analysis * Analyse the bytecode or the object code in a "non-optimized state" for easy to catch bugs. There are tools that are integrated in the IDE that can flag stuff as you type and the file is compiled on the fly. Then, there are programs that you can run against the code during build time that performs the same task, but in batch, and can create a report for you, flagging different things as low, medium, and high. * Coding Style Standard * There is a way to write an if clause, do you wrap it in a bracket every time? Do you do var=='const', or 'const'==var ? Do you use tabs or spaces? Do you require comments on every method/function detailing abilities and side effects? Are constants declared all upper case, are all unchanged variables marked as const or final? Do you limit scope for variables to the bare minimum (everything is public or only what needs to be exposed) ? You can enforce these rules with plugins or yacc/bison type processors. * Continuous Integration Server * As new code is checked into source control, the machine automatically checks it out and builds/test/deploy's it to the repository. You get an email detailing happened, and what went wrong. You can visit a page to see a report, and a graph of regression, or increased unit test success rate. If something breaks, you IMMEDIATELY see who broke it, and why. If you need to work on something special and it takes a few days: branch the code, then merge it back to mainline. Use your source control like it should be used! The machine's sole job is to compile, test, report, and then upload the finished product to the repository. * Use a Repository * Remove the ability to copy code directly to production, copy it from a repository. Ensure the repository can only be uploaded from the Continuous Integration machine. At a later date or time, you (or your deploy team) go to your prod machine, and copy the code version down from the repository. If you need to regress a version, copy the old version from the repository. * Code Coverage * Ensure your unit tests attempt to cover as much of the code as possible. There are tools that determine if your test code is ran through all the execution paths of your code. Any lines that aren't touched are flagged in a report. (Nobody is 100%, I suggest that 70-80% is fine). Also, any code that doesn't have SOME code coverage is flagged as a failed build in the Continuous Integration server. For Java: Static code analyzer: http://pmd.sourceforge.net/ Coding standard tool: http://checkstyle.sourceforge.net/ Continuous Integration: http://jenkins-ci.org/ Repository: http://www.sonatype.org/nexus/ Code Coverage: http://www.eclemma.org/jacoco/ --b Quoting Christopher Rimondi :

=============================================================== From: Eric Wolf ------------------------------------------------------ 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 rare) 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 -=--=---=----=----=---=--=-=--=---=----=---=--=-=- Eric B. Wolf 720-334-7734