Pay Down Your Debt

“The most powerful force in the universe is compound interest” – Albert Einstein

One hard lesson I have learned as an engineer is that technical debt pays in spades. If you continually modify a software system without paying down your technical debt, eventually you will have code that is difficult to maintain, unreadable, & a royal pain to work with. If you continually ignore the problem, you risk accumulating so much debt that it becomes very costly to correct the code.  Eventually the only option is to scrap the code and start from scratch.

Refactoring code periodically is one way to reduce technical debt. Refactoring is the activity of “modifying code to improve its structure or readability, while preserving its meaning or behavior” (thank-you Wikipedia). It is not a single technique, but a collection of techniques to remove technical debt. Think of it as a catalogue where you browse problem patterns & then read up on how to correct them.

It is important to embrace the practice of refactoring.  You will come across code that smells. The question is what you are going to do about it.

———-8<—————————————————–

If you do plan to refactor code, keep in mind that refactoring does not dismiss professional judgement. You as the creator or maintainer of code need to ask yourself the following before refactoring:

• Does the refactoring solve a specific readability or structuring defect?
• Will the refactoring cause issues when merging code?
• How long will it take to refactor this code? Do I have higher priority items to deal with?
• Will I be able to fully test the refactoring before my code review?

Me and my Mind Maps

As a follow up to my previous post, here is a snapshot of one of my technology mind maps:

For those who are curious, the tool I currently use is MindManager Lite 7 from MindJet.  I have also used FreeMind in the past.  It is a good, free alternative to MindManager if you do not want to spend the bucks.

What is ‘Better’?

People know nothing.

Many, many moons ago I attended my first philosophy class at university.  The title was ‘ The Philosophy of Science’.  I enjoyed that class very much and I will never forget what happened on the first day.

The professor came in and sat down on the table in front of us.  He introduced himself and the course, and then he went around the room to query us on our majors.  Since the majority of the class was majoring in computing science he then posed this question:

"How do you know when you have improved a computer?"

I immediately answered, smiling with confidence that I had the answer.

"When it is faster, better, and cheaper."

The professor thought for a second and then asked me "What is ‘better’"?

Things went downhill from there.  While the class agreed that you have improved the design of a computing system when it is better than the previous version, no one could truly define what that meant.  We would spout things like ‘bigger cache’ and ‘more megahertz’, but nothing truly captured what was a ‘better’ computer.

The big lesson at the end of the course was that you can never truly know anything.  You can only alter your perceptions of what you observe to reach a conclusion, but you can never truly know.

Ok, so what is my point?

I have been on a reading spree the past year.  I have re-read some books I have not touched in years, as well as new books in fields which I typically do not touch.  I have a listing of about 25 blogs I regularly read as well.  I have also subscribed to several podcasts which I also review regularly.  Every learning I have from these resources goes in to a small collection of mind maps.  I use these mind maps in many aspects of my life such as proofing emails, organizing my priorities, and storing important information.  While I cannot provide a single measurement of how I have improved, I know I am getting better:
 

• I can quickly locate information I read months ago when I need it
• I have caught defects using my every growing checklists
• I have improved the quality & clarity of my emails
• My day "feels" more productive and in control

"Better", as the story above outlines, is a relative & perceptual thing.  While I cannot define what ‘better’ is, I do know that the small improvements I have made have made me better.