Cycling is the art of not getting stuck on a problem. I term cycling as one’s ability to live at two distinct levels, the lowest level being the implementation and the highest level being abstract, i.e. the algorithm and problem scope. The term fast is the ability of a software developer to quickly move back and forth between the two.

Why

Software development is a process of functional breakdown of problems into algorithms and data structures. The difference between an entry-level developer and a more senior developer has a direct correlation to the speed at which the developer can cycle between various degrees of abstraction given the same problem. The net velocity and accuracy of the final solution based on the problem given to two developers is dependent on this fast cycling

Moving Past Roadblocks

During the cycling process, a developer can quickly recognize if a solution is either:

• Too complex. This is what I term “off in the weeds”. Developers without a keen insight into the problem space and executing too quickly on the solution build a system that while it may solve the problem is either difficult to test, overly complex to maintain, or a combination thereof. This manifests in the often “what the heck are they working on???" during team meetings.

• Too bug-prone. This is typically manifested by the “whack-a-mole”. If a developer can’t cycle up from the solution, and get a breath of air, they will often be stuck just knocking defect and defect with no convergence on a solution. This manifests in the message “still testing and fixing bugs”. A “test-first” methodology is preached to avoid this.

Your goal as a developer is to recognize both quickly as you move forward in your career. Seniority brings wisdom, not intelligence. A more senior Developer isn’t graded on how fast they code, they are graded on their wisdom.

When to Code First

The only time coding should be done first is to reduce the complexity of the problem space. I always recommend for complex problems that mapping the problem space, determining the data model, writing out how the user intends to use your system, and understanding the requirements (is this mission critical? does the speed of this operation matter? who is the intended audience?) This is critical to scoping the problem.

As a Developer gains more wisdom, what was daunting problems become simpler and therefore do not necessitate the scoping exercise. The goal of a Developer is to train your mind as to how to perceive a problem, formulate a hypothesis on a possible solution, then execute only as much as needed to validate the hypothesis and how the current implementation will satisfy the problem. This is called cycling down because you’re using your implementation to help move toward a final solution.

When enough code is written, the Developer should cycle up; recheck sequence diagrams, check flow charts, or review the speed (i.e. in O-notation) of the algorithm. It could also mean, “hey I have enough code, let me begin bracketing my work with a test harness”.

When a developer code first too quickly, the solution often is untestable. Ideally, no code should be untestable. If it is, there could be some serious issues with the architecture. You should always have the proper abstraction layers in place, shims designed, etc such that you can test at multiple levels. Again, if you cycle up to write a test and then realize it’s not testable, time to cycle down to figure out where you broke the abstraction layers and how can you remedy the untestable nature. If you spent too much time in the down cycle, then you will more than likely find that a huge refactor is needed.

Pay Attention to the Cycle Lengths

Cycle lengths generally are shorter during the initial phase of design and planning. At the terminus of a solution, your down cycles should be much longer given that your testing infrastructure is there, your API appears to be properly designed, and now, you just need to write the implementation. The need to spend a lot of time in the up cycle has been reduced because you’ve already invested in the cycles early in the planning and discovery phase.

Learn from your solution. How long did it take you? How many times did you refactor? Did you do enough design work (slow work) to facilitate speed (coding)?

FIG 2: Not Cycling Enough