The Code Refactoring Paradox

IDE’s have enabled a shortcut in the software design process.

Thinking through the problem and solving it before coding is required.

BUT

Thinking through code is not inherently necessary before starting to code anymore.

While working at ISS and working through a large and complex calculus project it became evident that there is a certain paradox of thinking through problems versus thinking through the code. While design is something that we would rather take to the notebook or white board, a calculator or other instruments in a software engineers problem solving environment (rather than their software development environment), thinking through code requires much different instrumentation. A page with strange boxes containing other boxes with arrows and numbers drawn from place to place is often an instrument of thinking through code. It seems that thinking through code is done for the purposes of forecasting maintenance, for following SOLID principles, especially the open close principle. The idea is that software engineers do not have to spend a ton of time refactoring such that the software can be easily extended. The whole point of test driven development is to have a timeline of what worked, making the software much more understandable with regard to extension. Many lecturers in the industry tell us that software engineers are not typists, that software engineers should not sit down and burn through the code, but the development process varies from software engineer to software engineer. Thinking through the problem is a nearly inarguable prerequisite to writing code. Yet, thinking through the code, is different, and nearly negligible. Solve the problem, start coding, read the code, refactor it to follow SOLID principles. This is the answer to performance in my opinion. What happens when we think through the code, is that we give ourselves too many imaginary constraints based off of what we think the details will be. In too many circumstances have I made too many abstract classes, too many interfaces, too much unnecessary cruft surrounding the structure of extendable code that is closed to modification especially. It becomes more time consuming to try and tape odd structures together in a fashionable way than it does to solve the problem completely code wise, and then refactor it into an extendable structure. This solves the problem of over-engineering and suites the agility required in most circumstances.

Set out to solve a sub problem

Solve it on paper, or some other Software Aided Design

Solve it in code willy nilly

Refactor it using a nice IDE like intelliJ for instance.

The nice and tidy code can be committed.

You could see the benefit if you have enough experience, and I can see some circumstances where thinking through the code is absolutely necessary before starting to code. However, IDE’s have provided us software engineers with a shortcut in the design process that needs to be acknowledged. IDE’s have provided more than just easy learning or fast coding, but fast structuring of code as well.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.