Dev Diary #1: We hate to see great code turn out poorly; this is how we save our own code from going south.
Author’s note: Welcome. This is our first-ever developer diary article. This column is dedicated to developer practices, habits, failures, and the lessons we learn when writing code. I’m not a developer, and hopefully that won’t be too apparent from my writing. I manage the online content at Three Point Turn and I bump elbows with the devs in our Toronto office.
Working beside the developers, I can tell you that many see development as a community. They discuss everything from open source libraries to networking events, huge mistakes to major breakthroughs. They’re really open about their work.
Normally, when I sit down to write a Turbine News article it involves a lot of online research and reading. When I began this Dev Diary column with the 3PT developers, I wanted to tap a different resource. In addition to the online research, I sit down with the developers one-at-a-time to discuss the topic of the entry. They’re not code monkeys – they have strong opinions about software. Over the next few weeks you’ll get to know many of the Three Point Turn developers and their position on various software issues. For better or for worse. – Rhys Mohun
Organizing and maintaining healthy code
We want to start off this column with a topic that we’re passionate about: organizing and maintaining healthy code. On more than one occasion, my conversation with a developer led to the practice of refactoring code regularly. Sounds great, but what happens when you’ve got client change requests piling up and a deadline around the corner? It takes a little extra commitment, but there is a solution.
First, we need to find out what makes code become inefficient in the first place. In addition to the 3PT developer comments, I found insight from Jim Bird who writes a blog at SWReflections. He mentions a few areas where good code falls apart.
- Poor code doesn’t necessarily come from lazy developers who don’t care about coding practices. Often, real-world pressures create a difficult environment for even the most organized developers.
- When multiple developers collaborate on the same code, they interpret sections differently.
- Too many undocumented workarounds to circumvent a major issue can compound to create inefficient code in the long run.
- Client change requests can derail a straightforward project, adding complexity to initially-clean code.
- Client expectations almost inevitably ignore the back end. Their concern focuses on the visual. This can influence the priorities of the developer.
- Working on top of another vendor’s code may mean a developer inherits inefficient code right from the start.
What the 3PT team thinks about common code-muddying problems
Lance is the head of operations at 3PT, and he comes from a development background himself. He is an advocate for open source development, and that’s his motive for keeping his code clean. I’d asked him about whether keeping code legible was a priority;
“You don’t need to if you don’t need to, but it’s not always going to be your code. Some day that code that you understand, that you’re familiar with, is going to go to someone else. And there’s no need for them to spend hours or days sorting through it.”
(Lance Slack, COO at Three Point Turn)
Grant is a user experience developer at Three Point Turn. He’s constantly balancing the need for attractive front-end interfaces against clean, simple back-end code. He brings up a common developer dilemma.
“Obviously everyone strives for the cleanest code possible – under some circumstances it just isn’t realistic. Code often starts off clean, but after enough [client] requests it goes from tight to sloppy. You’re sometimes working through the mess just to get it done.”
(Grant Madsen, Software Developer at Three Point Turn)
Just getting it done seems to be a painful but necessary evil when dealing with client deadlines and progress reports. What can you do when you’ve got no time to tend to your unwinding code?
Chris Mihalicz is the 3PT CEO, I typically find him hammering out code in his office or with the developers. He understands the pressures that demanding clients can bring to a project, and the get-it-done attitude that is sometimes needed to wrap up a tight deliverable. He suggests a little extra commitment outside of project hours to refactor your work.
“Some clients don’t care about the back end. At times a timeline doesn’t include refactoring, so you refactor on your own time. Always plan to refactor your code, but during crunch-time, you need to work through it. It takes a little extra commitment, but there is a solution.”
(Chris Mihalicz, CEO at Three Point Turn)
It pays off in the long run. Why restrict your own efficiency during project hours with messy code, when a small commitment of outside time can virtually clean up the code for the next day? Have you ever gotten to the point when code is so inefficient that you consider a rewrite to move forward?
“You can write good code on top of bad code – it’s just not ideal. A rewrite isn’t always the answer.”
(Chris Mihalicz, CEO at Three Point Turn)
Chris suggests avoiding wasted rewrite time by refactoring work outside of project hours. Put in the time to keep your code healthy. You will feel the benefits the next day, the next week , when your code stays on schedule. Enjoy working with clean code, and take pride in your work.
That seems to be one of the inherent attractions to being a developer. That code is your work, in your name and in your style. It’s definitely something to be proud of if you spend the time nurturing it.
But what do I know, I just work here. Thanks for reading.