After solving a problem that has perplexed me for hours, I often take a few moments to sit back and bask in the bliss of a problem well-solved. But sometimes, my joy fades when I realize how little progress I made towards finishing the feature I started. I got distracted. I started out on track; but somehow, my focus shifted away from the goal—implementing the feature.
Most distractions have good intentions behind them. Sometimes I see a way to use the coding pattern I recently read about and decide to experiment. Other times I find a piece of code that I intended to refactor but never got around to; thinking it will only take a minute, I jump into that refactor. And still other times, I get distracted by formatting details, eliminating whitespace, converting a css file to sass, or attempting to make some method run more efficiently. While these are all great areas to focus on, they’ve ultimately prevented the feature from functioning sooner.
How can I complete the feature I began and still ensure my code is clean and well factored?
The State of the Code
Some the most fundamental programming techniques in the Ruby community have a side-effect of preventing distractions. Pair programming utilizes a second programmer’s perspective to discourage distractions. And yet still pair programmers may wander off together. Test Driven Development sets a rigid cycle of “red-green-refactor” to keep the focus on the task at hand. But the direction of building code is still at the programmer’s discretion. Regardless of the technique, a programmer needs a guide to remain on track.
FREE-style programming aims to be such a guide for programmers. It walks a programmer through an ordered code state.
- Functional: Proven to work as expected.
- Readable: Does what it says.
- Easy to change: SOLID, documented, adaptable and extensible.
- Efficient: Performs at the highest possible level.
This acronym gives an order to the state of the code while implementing a feature. First, you should focus on making sure to solve the problem you set out to address. For me, this is passing the acceptance test and its underlying unit tests. Next, a programmer should aim to make the code readable: DRY-ing up the code, creating small private methods doing the work called from the public methods, renaming methods to clarify what it does, or even refactoring to extract method into a class. Once it is readable, the code should become easy to change. This could be done by breaking the more complex classes into meaningful, smaller, reusable ones or by adhering to “open for extension, closed for modification”. Finally, the code should become efficient. The emphasis here is on execution performance.
When to shift to the next code state
A critical awareness is knowing when to move to the next code state. When is the code functional enough to move to readable? Or when does a program benefit from becoming more readable even though it is not yet completely functional?
Knowing when to progress is a developed skill. There is no absolute signal to tell us when to stop, go, or proceed with caution. The time to move forward is when you feel that the code stage is complete. When you sense this feeling, transition to the next code state.
Sometimes I do break this rule by taking little excursions to make the code readable without first making it completely functional. I do this only out of necessity, however. I make small adjustments to the readability of the code so that I can understand it enough to implement the next function. The F-R transition is the only time I consider moving backward. I only progress to “Easy to change” and “Efficient” stages after the code is fully Functional and Readable.
What kind of programmer are you?
In my experience, programmers are divided by what they prefer to focus on. Many are driven to make their programs function. These people are often task-oriented and they become annoyed when there are lists of stories that need to be addressed. Others, like me, are distracted by how the pieces fit together. The details of a program’s implementation feel more important than its execution. A common worry among these programmers is to commit the perfect solution the first time. Lastly, some programmers focus foremost on performance of their code. A performance-focused programmer will tinker with a single method or construct for even the slightest gains in speed, but later must re-tune the methods to meet the additional requirements.
We need all types of programmers. It would take a tremendous amount of time to get an application running if there wasn’t a drive to get features working. However, a system becomes a tangled mess if it is not cultivated. If the time required to insert a new feature into a system becomes less profitable than the feature itself, we stop implementing features. So we need the sustaining programmer to keep the system from grinding to a halt. But sometimes code can function and read well but still not be efficient. That’s when the performance programmer shines—taking the proven-complete, well-designed code and optimizing it to work faster.
A Balanced Approach
Building a software system is difficult. The demands of adding a new feature now often cause shortcuts that inhibit the development of future features. And yet, taking the time to clean up code distracts from adding features. True success of a system relies on a balanced approach to coding.
Using the FREE-style guide gives this balanced approach. Start by proving a feature is Functional. Then change the names, formatting, and method size to make it Readable. Afterward, isolate code that relates to each so that it is Easy to change. And lastly, look to improve the overall performance through efforts to make it more Efficient.
By following the FREE-style guide, I’ve been able to identify and re-focus when I get distracted. I’ve been more productive, while simultaneously writing lasting code. I hope it will help you, too.