How To Avoid Writing Terrible Code

Writing quality code can be a challenge for any organization. At TidalScale, we to go to great effort not to write terrible code. And while that might seem absurdly obvious, in a fast-growth environment, it doesn't exactly come easy. Here's some of what we do to make sure we come up with the good stuff.

Emphasize Quality over Quantity & Speed

We've all hacked something together to make a deadline, but this just pushes more work into the future and magnifies development costs. But here at TidalScale, we try to hold ourselves to a higher standard and, virtually always, our best course of action is to focus on correctness and performance instead of how quickly we can code. For instance, we:

  • Avoid crazy deadlines, but limit the damage when they happen. This means schedule the followup, review and necessary cleanup. We have a "technical debt" feature for just this reason.
  • Do it right whenever possible. The truism, "there's never time to do it right, but there is always time to do it over," isn't true. Just ask for the time, write a spec, get the code review you need today, before committing more technical debt for tomorrow.
  • "Commit it all and let Jenkins sort it out." This works, but remember, you can do this on your own branch first.

Leverage Knowledge & Obtained Wisdom

We will always know more tomorrow than we know today. But this does not mean we were idiots last year, even when last year's code seems dumb today. As we learn more about the markets and customers our product addresses, we must develop new requirements and insights.

  • No one owns code here, but when working on old code do consult the original authors. As you work on code, add your name to the comment at the top of the file.
  • Code, concepts and specifications are not cut in stone. We must re-examine our work, incorporate new thinking, specify new code, and rewrite old code as a necessary part of the process.
  • New features and feature updates must begin with a specification. A specification is a living document in the wiki, which has been circulated amongst the team and meets the team's requirements for completeness before coding begins.

Focus on the Right Metrics: Correctness, Performance & 'Wowed' Customers

We use Jenkins to enable a test-driven methodology. Our count of closed cards or number of commits does not mean much unless Jenkins and our customers tell us the product is better.

  • Use the "code review" column – it's there for a reason. In our agile process we have a "state" defined for code review. All it takes is one other person to put his or her eyeballs on your code, and it's always worth the time.
  • Jenkins and then our customers are the final judges. Our intuition is meaningless until it is externally validated. Wherever possible smoke-test your hypothesis on a dev system, but never hesitate to use the correctness or performance pipelines in Jenkins to test your branch or commit. Our work is always customer visible, so follow through with sales and customer relations to make sure we've met the objective. At TidalScale, engineers do not throw code over the wall.

We are Top Engineers Using a Good Process

What we are doing and how we do it are always open for question and improvement. We are not stuck doing things one way, just because that's the way it's always been done!

  • Turn off notifications for email and chat and focus for a few hours every day. If necessary, only respond to direct communication or the channel for your specific project.
  • Hold each other accountable, be respectful in your communication, and remember that in email and chat it is too easy to give and take offense. One voice call can head-off conflict and avoid a coding marathon where a quick fix will do.
  • The next person we hire is the most critical decision we will make that day. The interview process must not be easy on a candidate, and every candidate must be evaluated for:
    • People skills
    • Technical ability
    • Cultural diversity

Take the Time to be Responsible

Good code does not write itself, and the most brilliant engineer does not automatically write good code. Write the test first and get it into Jenkins. Good code is correct, performant and maintainable.

  • When implementing a new feature at TidalScale, we can often run a test on an alternate hypervisor for comparison. This baseline (or a useful alternate) is extremely useful for comparison and must be incorporated in the Jenkins report.
  • When revising or fixing code, identify the regression or correctness test and use it iteratively as you work. Where possible, use Jenkins to run tests in parallel as you proceed.
  • Have a peer on the team review your code. All parties should go into the review as if no one owns the code. And always talk only about the code – never about the author.

No matter where you do your coding, I hope these guidelines help you come up with quality code consistently. They're certainly working for us.

Topics: innovation, start ups