www.hans-eric.com

I’ve come across many different types of developers during my nearly two decades in the business. In my experience there are two developer character type extremes: the ones that always seek and settle with the simplest solution, and the ones that seek the perfect solution, perfect in terms of efficiency, readability or code elegance.

Developers from the first group constantly create mess and agony among fellow developers. The second group contain developers that never produce anything of value since they care more for the code than they do for the result. The optimal balance is somewhere in between, but regardless of what type of developer you are: you should always start by making it work, meaning implement the simplest solution first.

Why spend time on an implementation that isn’t likely to be the final one, you might ask. Here’s why:

1. The simple solution helps evolving the unit-testing safety net.
2. The simple solution provide rapid feedback, and may prevent extensive coding of the wrong feature. It is like a prototype on the code level.
3. The simple solution is often good enough, and – with a working solution ready – you are less inclined to proceed and implement a more complex solution unless you really have to. Thus avoiding premature optimization and premature design, that makes you add features that might be needed in the future.
4. With the simple solution in place, most integration and programming interfacing is done. That makes it easier to implement a more complex solution.
5. While implementing the simple solution, your knowledge of the system increases. This helps you make good decisions later on.

This may all sound simple enough to you. After all, the habit of Making It Work First comes naturally to many developers. Unfortunately, for me, I’m not one of those developers. I still let more or less insignificant design issues consume an unnecessary amount of time. The thing is, it is hard to find the perfect design on the first try. The perfect design may not even exist, or cost too much to be worth the effort.

That is why I struggle to attain the habit of Making It Work First.

Previous posts in the 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
4. Tools of The Effective Developer: Customer View
5. Tools of The Effective Developer: Fail Fast!

I’m back from my three week vacation!

I had a great time, but as suspected I wasn’t able to stay away from computers. In the warm evenings, just for fun, I started to implement a ray tracer in the D Programming Language.

I have been looking for a suitable project that would give me a chance to get deep into D, and a ray tracer seems to be the perfect fit. D is supposed to be great at floating point programming and now I have the chance to find out on my own.

To make it a little more interesting I have used a more top-down breath-first kind of approach than I normally do. I want to see how that affects a test-driven development technique. As a part of the experiment I keep a detailed development log which I plan to share with you when I reach a certain point. It could be within a week or take several months depending on work load and inspiration level.

So stay tuned. I’ll be back with ray tracing, or other topics that comes across my sphere of interest.

Cheers!

In a comment to my previous post AC wonders how I automate acceptance testing. He considers that as being done by real testers. Well, he’s absolutely right. I expressed myself a bit sloppy, so let me use this post to explain what I meant to say.

Acceptance testing is done by the customer to make sure she got what she ordered, to make sure you delivered the right system. This process cannot and should not be automated. What you can do – and this was what I meant to say – is to automate acceptance tests, and use them during construction.

The customer defines the acceptance tests. These are valuable to the developer since they can be used to validate the system as it develops. The sooner you get a hold on these test cases the better, so make sure you press the customer to produce them early. Better yet, help the customer in the process. That way you can help making the test cases automatable.

So, how do you design a test so that it can be automated? First of all you need to stop thinking in terms of user interface. Instead you should describe the test, in plain text, and in terms of action, function and result. Look for possible test data, edge cases, exceptional uses and describe those as well.

The second thing you need to do is to make the system in such a way that it can be automated. Separating the GUI from the business logic is often all you need to do to achieve that. You then automate the acceptance tests in the same way as you automate integration tests. In fact, they could even become a part of your integration testing harness. The only difference being the fact that they are defined by the customer.

I’m not saying this is easy. (Here’s a nice post which discusses when to automate.) I’m not saying it can be done for all of your acceptance tests. What I say is: it can be done for far more tests than you might think. For example, we are customizing a GIS system for an internal customer’s needs. The application is user controlled and involve plenty of complex actions, modifying graphical data and properties. Still we were able to automate most of the acceptance tests.

We spent a lot of time writing code to set up fixtures, initiate actions and check the results. It was worth every second though. You see, manually running one of our acceptance test cases usually takes several minutes. By having the computer do all the work, time is reduced significantly and free up developer time. We use the automated test cases individually, almost like an extended compiler, to verify features as we implement them. And at night we run all of our acceptance tests to get feedback on how far we’ve come and to spot unexpected problems.

But the real acceptance testing is still going to be done manually, by the customer, at the end of the project. Just like AC pointed out.

Cheers!

It’s a well known fact that we regularly introduce errors with the code we write. Chances are slim to get it right on the first try. If we do, the risk is great that changing requirements and murdering deadlines will mess things up later on.

It’s also well known that the cost of failure increases with time. The sooner you discover the flaw, the easier it is to fix. In other words, if we are going to fail, there are good reasons to do it fast.

When developers talk about failing fast they usually refer to the defensive coding technique that is based on assertions and exception handling. It’s true that assertions are the very foundation of failing fast, they should be your first line of defense against bugs. But it doesn’t stop there. Failing fast should pervade your whole process of making software. You should fail fast on all levels.

The most effective fail fast-technique is automated testing, the fastest way to get feedback. Be sure to write the tests first. And don’t just automate unit-testing; integration and acceptance testing are often easier to automate than you might think. The key is to isolate your code using mock objects.

The fail-fast property doesn’t apply to code and systems alone. It should be used on the project level too. By using agile practices like short iterations, small releases, and on-site customers you create an environment of continuous feedback. It will help you steer the project to success, or – by failing fast – avoid a disaster. Kate Gregory puts it this way in a nice post from 2005:

“Failure can be a good thing. If it saves you from following a doomed path for a year, you’re glad to have failed early rather than late.”

Failing takes courage, failing increases your knowledge, failing calls upon action. That’s why I like the habit of Failing Fast.

This was the fifth post in this series. Here are the other Tools of The Effective Developer posts:

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
4. Tools of The Effective Developer: Customer View

I stumbled upon this really interesting site. It implements a new kind of site navigation that is really cool. It’s actually a research project that tried to create a user interface which requires no clicking.

For me it was a mind-tumbling experience, but I quickly got a hang of it. I even liked it to some extent. I had two major problems with it though: First there were a lot of movement going on. A little too much for my old fashioned taste.

The second and more important problem was that the mouse pointer got in my way while reading. In a normal click-based interface I could just drag it out of sight, but here I needed to have it hovering over the item to keep it enlarged. This was annoying, but they should be able to reduce the problem with more whitespace around the enlarged items.

I haven’t tried the interface enough to come with a deep analysis, but my guess is that it won’t replace the traditional click-based navigation. At least not in the near future.

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

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!

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

A comment on a recent post of mine made me think more about the distinction between a Software Programmer and a Software Developer. To me there is a subtle, but important difference. Let me give you my definition:

A Software Programmer is someone who really knows the environment he is programming. He knows everything there is to know about the language, the API and the Framework he’s using. He can do low level optimizations because he knows in detail what the compiler does behind the scenes. He is indeed a Wizard and a Guru of his domain. A Software Programmer usually starts with the implementation (probably because that’s what he is doing best) and work his way outwards.

A Software Developer on the other hand is a specialist at giving the customer (user) what he wants and what he needs. He doesn’t waste time on premature optimizations; he prioritize maintainability over performance, unless the performance is proved to be unacceptable; he has great testing skills, designing skills and communication skills; He is empathic, knows his HCI, and cares more about the user than he cares about his code. He cares so much that he usually becomes an expert himself of the users domains. A Software Developer starts with the interface (probably because that’s what he does best) and work his way inwards.

A person can be both, or more of one or the other. In a team you want both kinds but they are rarely found within the same individual. I, for instance, consider myself a great developer but an intermediate programmer. One simple way to test what type you are is to ask yourself this question: Do I care more for the interface (GUI or Programming Interface) than I do for the implementation? If you think the implementation is unimportant as long as it does what you want, and is reasonably maintainable, then you’re probably a Software Developer. If you find the previous sentence a blasphemy, you could be a Software Programmer. Which one is it?

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.