Wishful thinking is one of those concepts that really struct a chord when I was studying theoretical computer science. The term was introduced on a introductory programming course, and I believe it originated from the MIT “SICP” course authors. “Wishful thinking” basically means that a developer sets aside some problematic details, for a while, in order to effectively work on another part of the same problem. In practical terms, you can create an interface (or a dummy function with input parameters)  and pretend that it does the thing it will eventually do. For now, you can just use a static ‘return’ clause and make the call superficially work as intended.

What’s the Code gremlin?

Wouldn’t it be super, if you could go home, and let someone clean up your code base while you were asleep? This is the Code Gremlin I was thinking about: just insert the guy through your laptop’s USB port, and with its magical powers it cleans up any mess, whatsoever, that was left after a busy day of coding.

Less strain on brain; no bad line justifications. Documented functions, yes please. No weird ‘tmpNet’ variable names, will do! Modules written in lengths that are easily absorbed, and make perfect sense to future code reuse needs.

Refactoring aims to change software’s static structure – the source code. It’s not often so much about the performance (run-time), but rather how a developer perceives the source code. You might even say, the ‘elegance’ or ‘beauty’ of the code.

Refactoring itself can be a beneficial mental process, during which developer takes a second glance at the form of the solution; it might also reveal bugs.

Legos

Stack Overflow. It’s right there! That’s your solution. Click, hooooold, done. Then Paste! Compiles? Good! I’m finished.

Yeah I know. Copy paste coding. We all do it. It’s the little brother of open source. Come on. Don’t stare at me. It works.

I watch daily how two guys, brothers S and L, are doing fascinating play with Legos. Those were my favorite blocks some 35 years ago, too. There’s two methods to building legos:

1. you buy a boxed set, open the manual, and build that particular thing according to the instructions
2. you pour hundreds of colorful pieces on the floor and start experimenting

Not going too deep philosophically into the ‘Code and legos’ paradigm, I can say that doing code often has both of those methods at some phase. And it’s important to be able to do both. Sometimes you have (1) the blueprints available, sometimes you don’t. Fundamental building blocks — in code — are the reserved keywords and functions in standard libraries (packages).

“Stretch and rebound”: causes for the need to refactor

Many times there are phases in a software project, during which a developer ‘stretches’: makes an adamant commitment to work until a feature works; however rudimentary, but still it “works”. Psychologically it’s tremendously liberating. You have a gut feeling that you’ve proven something to be feasible.

From the solution you’ll “rebound”: return to your upstream requirements. Often in practical software engineering we do code for “someone in need”: our code will be consumed; for example, in order to make a View in a a mobile software, we construct components: buttons, scrollable areas, lists, etc. When we finish doing the early prototypes of these building blocks, we rebound back to the “top” level (the View) and start tying the knots and making it all work together. Often the component placement means that we must supply some sort of parameters to the components.

This time of rebound is also a kind of turning point where we might ask “Was the component good enough? Should I polish it a little bit?” We’re talking refactoring here.

Case example: doing REST call code

Say, you’re making the network connectivity features, and the first RESTful API call requires some more boilerplate code than you ever thought. The concept is something that you know is viable, so you start stretching the solution: create all variables you might need; crunch the call string (doesn’t care yet how it looks), and fire a first call to see what possibly happens. You get an answer, so lo and behold! You know the server has received your packet of data! That’s great! Encouraged by this you add bit more to the code to really get going. In fact, you need to do some parsing on the return packet. Then you need to wire the error handling code, and… more. You now got some 50 lines of code, which indeed seems to work.

We’re at the rebound point. You can take the “Go-ahead pill“, or the “Refactor pill“. The choice is yours. The implications of these, as in Matrix, are not so evident, as I’ll cover in another article.

This is indeed quite an important approach. During a stretch, it might feel uncertain and being out there in a jungle, without a compass, you as a developer are also putting a lot at stake: there’s a chance that the solutions a) won’t work b) was completely the wrong one to begin with. But nevertheless those stretches are crucial for keeping the velocity (going forward) in a project.

You are trading risk for risk: by taking some risk you alleviate the risk of being faced with an unknown task, of whose complexity you cannot say anything certain. Now that you’ve done the rudimentary code, you know a thing is doable, and you know the basic solution structure.

The tendency to favor even hasty development to stagnation is actually very healthy. The thing that’s often forgone is that if you never clean up the mess, it’s going to be what you’ll stare for a long time – maybe not this month, or even this year, but believe me – there are no code gremlins that tidy up things automatically for you, when you’re asleep.