Good Advice

First, this advice didn’t come from me;  I just like it so much that I want everyone to know about it.

I recently began reading the Object Mentor Blog and I came across this post, and it has really stuck a chord with me.  So often I find myself trying to hurry up and get it done, and that usually produces less than good code, which means I have to go back and fix it later or someone else will have to clean up my mess, which is no fun and embarrassing to say the least.  If, however, I take the time to carefully plan out what it is I am creating, use Test Driven Development, and slow down, etc, then the code I have just made will be less likely to break.

We delude ourselves that speed is better.  Not always.

Here are a few things “Uncle Bob” mentions in his blog post to be a professional craftsman:

1) Adopt an attitude of calm

2) Focus on the problem to be solved.

3) Solve the problem step by step without rushing

4) “When you feel the temptation to rush, resist it. Leave the keyboard and walk around. Distract yourself with something else. Do not give in to the call of your addiction.”

I am going to start remembering and implementing these suggestions;  I think I’ll be a better software engineer for it.  Thanks Uncle Bob.

As an update to the above about speed killing, I just read a post by Martin Fowler about Technical Debt.  Sometimes it may be good to deliver fast, poorly designed code that will cause you problems later in order to make an investment in the project, hit deadlines, etc knowing you will have to go back and refactor.


3 thoughts on “Good Advice

  1. Good point about the Technical Debt. A project has no value when it has no future. When the failure to meet a critical deadline would result in the termination of a project, then the choice to cut whatever corners in order to meet that deadline is obvious. What is missing from view to the project’s stakeholders is that the intangible value/potential has been compromised.

    Its that intangibility that is the real trouble.

    1. Do you think that Test Driven Development helps in reducing Technical Debt while still allowing you to meet deadlines? In my limited experience with TDD it seems to make a difference. I think the main overhead with TDD is learning how to write good test, which in the beginning may take some time, but once you get the hang of it, it certainly reduces errors ,encourages solid design, and keeps you focused. What do you think?

  2. I think its fair to say that TDD usually helps but is a means rather than an end. One of the side benefits of TDD is that it usually means that the developer has to take a step back from the code itself and crystalise their thinking in the form of unit tests first. This means that when they write their real code, this then this is at least the second time that they have had to think about what they are doing.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s