www.hans-eric.com

A post on Jeff Atwood’s excellent blog inspired me to write up the fourth element of my Tools of The Effective Developer series. This time I’ll handle the habit of taking the customer’s view.

Jeff states that the primary responsibility of a software developer is not to write code, it’s to solve the customer’s problem. (Otherwise, using my definitions, he is a programmer and not a developer.) This calls for the habit of taking the customer’s view in every step of the development cycle. Make it a habit to ask yourself the question: In what way does this matter to the customer? This simple question is like a good friend of mine. It’s stopping me from making costly mistakes and helps me focus on what’s important. Like getting the right things done, and not just things done right.

By taking the Customer View you help preventing technology-based decisions. I once read a report that was going to be the basic input for a decision to replace a legacy system. The author’s main reason was to have an object oriented system. Why would this matter to the customer? While there are perfectly good reasons to have an object oriented system, none of them could be found in the report. Nor could any of the really valid reasons, like usability and functionality issues.

The report-writers obviously didn’t take the customer’s point of view, but the decision was made none the less. So what happened you ask? Still not finished, many times the initial budget spent.

Being able to look upon your work from the customer’s point of view takes empathy, the finest characteristics of them all. Exercising it regularly is something all of us should do. That’s why I like the habit of taking the Customer View.

Here are the other posts in my Tools of The Effective Developer series:

1. Tools of The Effective Developer: Personal Logs
2. Tools of The Effective Developer: Personal Planning
3. Tools of The Effective Developer: Programming by Intention

This is the third post in my Tools of The Effective Developer series. The other two discussed the habit of keeping personal logs, and the habit of daily planning. Now the time has come to the habit of programming by intention.

Please note that I’m not speaking of intentional programming, which by the way introduces some interesting concepts. Instead I refer to the simple kind that only requires your brain and the programming language of your choice.

So what is programming by intention? Well, I like to describe it this way: if you are to implement a new set of functionality, and you don’t start with the implementation, nor the programming interface, but you start writing the code that is going to use it – then you are programming by intention.

Why is this way better? The short answer is: Because we are lazy. The long answer is: We humans usually seek the simplest solution. Start with the utilizing code and you should find yourself pushing complex code and decisions right where it should be: behind the programming interface, nicely encapsulated. We also focus more on the task at hand, which decreases the risk of committing the sin of premature generalization.

Programming by Intention is probably the easiest effective developer habit to acquire. It can be done at all levels of abstraction and there is no overhead cost. Therefor it’s my favorite habit.

I have a confession to make: I used to be addicted to debugging. Yes, it’s true. When I got hooked – damn you Delphi – I wasn’t able to see the dark side, the demonic side of the debugger. It lured me into the path of quick fixes. Heed my warning: debuggers are bad!

Fortunately I’m one of the lucky few who have been able to recover from this particularly addictive behavior. I’ve been clean – thank you jUnit – for almost 5 years now. And you can do it too, you can let go of the safety zone that these integrated debuggers provide, and break free just like I did.

The first thing to do is to realize that there is a better alternative: test-driven development. To get rid of a bug, the right thing to do is not to fire up your debugger, but to write a unit-test to reveal it. If necessary, keep writing tests and go deeper and deeper into your code. Eventually the tests will tell you what is wrong, and they’ll even point out a solution for you.

I know that using a debugger may seem like a faster way to find and extinguish a bug, but that is just an illusion. Here are the reasons:

1. TDD improves the design. Being forced to think testability tends to divide your code into small manageable pieces. This will make your code a bad breeding ground for bugs.
2. Tests remain useful for a long time. They become an addition to your testing harness, which helps protecting your code against future infestations. The work spent in a debugging session can never be reused.
3. Unit-testing saves time, a lot! While this isn’t immediately obvious, the long term effects are huge. Think of it: all those debugging sessions can be run automatically at your command, whenever you want, how often you want, and in just a matter of seconds. All you have to do to achieve this is to let go of the debugger, and write relevant tests.
4. Unit-testing gives you courage. There’s nothing like a good harness to make you feel invincible. I still remember the first time I felt the real power of unit-testing. I was working on a huge legacy application and had developed a new set of functionalities, using TDD for the very first time. Several months later I realized I had to do a major rewrite. The rewrite was risky business and took me a couple of days to complete. When finished, I ran the unit-tests which all came out green! I could be confident the program worked just as before the rewrite. And the best part: I drew the conclusion out of just five seconds of testing. Boy, I still get the goose bumps.

[PREACHING OFF]

Of course debuggers are useful tools. In certain situations they are even invaluable. For someone who’s new to the software they provide a great way of getting to know it. The problem is that a debugger makes you lazy. So be sure to get rid of it as soon as you identify a testing strategy.

Cheers!

Today, for the first time since I let FeedBurner collect my visitor stats, I examined the numbers more closely. I was quite surprised to find that Firefox so totally dominated the web browser statistics. Almost 7 out of 10 visitors were using Firefox 2.0.

The reason I got so surprised was that the figure was something like 10% the last time I heard. (Get off my back will you! I’m not a web developer 😉 ). I realized that those numbers must have been several years old, so I did a little googling and came up with some fresh statistics (which by the way showed that Firefox was at 10% in 2004):

It seems like Internet Explorer has 58.5% of the market, but only 11% among my visitors. From these numbers and the fact that you (my dear reader) is most likely a developer, I draw the following conclusions:

1. Firefox rocks among developers, and
2. Internet Explorer is a bleeding product

It is also interesting to see the relatively big differences in Safari (4% vs 1.5%), Opera (3% vs 1.9%) and Other browsers (9% vs 2.2%). I don’t know what to make of it though.

FeedBurner is awesome by the way. No wonder Google bought them.

In the first post of this series I stated that the best tools, the ones that make developers efficient, are the habits that they possess. The habit I referred to in that post was the habit of keeping personal logs. In this post I will tell you about another habit that helps me in my daily work: The habit of personal planning.

When I come to work, the first thing I do after catching up on the e-mails, is grabbing a pen and notebook and start listing today’s tasks. When I’m done listing the ones that are in my head, I turn to my work log and my calendar in search for more things to be done. At this point I usually have a big unordered list of tasks with various degree of importance. It’s always more than enough for one days work so I start prioritizing.

In order to prioritize I rip out the page of my notebook to start a new list. Then I bring the tasks back to the notebook in order of importance. This time I draw a small square in front of every item, turning them into a proper todo-list. When finished I can start the real work, taking on the tasks one by one.

The planning usually takes around ten minutes to do and is worth every second. There are three main reasons for me to do it, listed here in order of importance:

1. It helps me do the right things in the right order, making me better focused and more effective.
2. Because of the importance of closure. When I finish a task, the ceremony of checking the square makes me feel good and brings me energy to take on the next task.
3. It helps me remember what I’ve done during the day. This comes in handy when it’s time to update my work log.

I have tried several applications to help me in my planning, applications like Notepad, Microsoft Outlook and iGoogle’s todo-list. None of them could, in my opinion, compete with the good old pen and paper, so that is what I recommend using. But remember: it’s not the tool that matters, it’s the habit.

Cheers

It’s not without sadness I see that what used to be my favorite language has taken a big dive in popularity recent years. Now Borland Delphi is only the 14th most popular programming language according to TIOBE Programming Community Index as per august 2007. That is five ranks lower than one year ago, and far from it’s golden days in the mid 1990’s.

Delphi was really a great language to work with. In the early days it was a strong, even leading power in the programming community. It gave us one of the first RAD environments, which sure as hell was more visual than Visual C++ and Visual Basic, its competitors at the time.

But the popularity decline didn’t come as a surprise. It started with Microsoft snatching Anders Hejlsberg, the compiler genius who created Delphi’s predecessor Turbo Pascal. Following that, the increasingly lower quality releases and the name changing mess. For some unintelligible reason Borland changed its name to Inprise, only to change it back a couple of years later, most likely due to an internal revolt. Slowly but steadily even the most devoted started to leave for other, obviously better, alternatives.

Last year Borland announced that they were selling all of its development tools, including Delphi. It long looked as if Delphi would be brought back under the name of Turbo Delphi, but the sale was canceled. Instead the development tools were spun off into a new company, owned by Borland. Since then Delphi 2007 for Win32 has been released, the best release in many many many years. They really did shape up, but I’m afraid it’s too late. The magic is gone and I have moved on.

Farewell my friend.

When people talk about tools in the context of software development, they usually refer to stuff like Integrated Development Editors, Automatic Build Systems, Testing Frameworks, Documentation Extractors, or other useful applications that makes their lives as developers easier. Those are all great and productive tools, but they are not the most valuable ones. What really makes an effective developer is the habits he or she possesses.

One such habit, that helps me tremendously in my work, is keeping personal logs. I keep all kinds of logs: a work diary, a solutions log, books I’ve read, ideas I’ve had, a success journal. Well, to be honest, the last one doesn’t have much content; probably because of my Swedish background. For us “modesty is a virtue” and that’s what’s holding me back. At least that’s what I tell myself. 😉

When I keep a journal I prefer a simple format. Usually word documents are sufficient, sometimes with a special header format that visually separates the notes. There are times when I use a Wiki, but since I prefer a chronological order I tend to go with simple documents. They are easier to move around, and with tools like Google Desktop Search there’s no need for firing up a database to hold my straggling thoughts.

I like to think of the solutions log as the bare minimum, something that every developer should have. Of all my journals that I keep, I value the solutions log most. This is because it’s the most useful one, but also the easiest one to update. Whenever I run into a problem that doesn’t have an obvious solution, I follow the same pattern:

1. Search the Internet for a solution. Nine times out of ten this puts me right back on track within minutes.
2. If I can’t find a solution on the Internet I ask a colleague.
3. If a colleague can’t help me (this is also a nine out of ten-er), then I have to find the solution on my own. This is a tedious task. Good thing it doesn’t happen very often.
4. I document the solution in my solutions log.

My solutions log have the form of Q&A. But instead of questions it has problems, and the answers are called solutions. My P&S (as I call it) have helped me many times, because problems have a tendency to resurface. When they do – often years later – I know where to look for a quick solution.

I’m also very fond of my book log. I read a lot of books and to keep a track of them I make short notes. I don’t write fully fledged reviews but small notes on how I found the book and what I learned from reading it. Whenever I come across a topic I know I’ve read about, I consult my book journal. The notes there work like triggers that bring back the memories of the subject.

This was the first post in my new series: Tools of The Effective Developer. If you have an idea you want to share of an invaluable tool, send me a comment and maybe I’ll add it to my Blog Post Ideas Log.

Cheers! 🙂