www.hans-eric.com

Paul W. Homer has a post up discussing essential development problems. While this is a huge subject (somewhat reflected by the size Paul’s article,) I’d like to emphasize one of the things he touches: the lack of understanding the users’ problem domain.

The biggest problem in most systems today is the total failure of the programmers to have any empathy for their users.

I too have a similar perception, and I have many times been guilty as charged, although I’ve come to realize that I’d better take the Customer View if I want to succeed. Still, I fail from time to time in the analysis of the users’ situation. I don’t know why this keeps happening, but I think impatience and a strong wish to “get going” is partly to blame.

One part of the problem could also be how many of us look upon system development. We usually decide for technology at an early stage, often on grounds that matters little to the end users. Things like personal preference and hype usually have a big impact on the choices we make. We then build the system pretty much bottom-up, adapting the business process to fit the technology. I’ve seen this unspoken philosophy many times in many places, and the results are usually poor.

The cure is a change of paradigm. We need to start with the users, identify and help develop their processes before we build systems that support them. We need to realize that the system is not the solution; it’s just a part of it.

Another part of the problem is a question of attitude. We need to accept that we’re actually in the support business. Our job is to make things easier for others, not to take the easy way out on the users’ expense, as Paul also points out.

“Use this because I think it works, and I can do it”, produces an arrogant array of badly behaving, but pragmatically convenient code. That of course is backwards, if the code needs to be ‘hard’ to make the user experience ‘simple’ then that is the actual work that needs to be done. Making the code ‘simple’, and dismissing the complaints from the users, is a cop-out to put it mildly.

Of course, there is a trade-off between what users want and what we can provide, but at least we need to start at the right end.

Cheers!

Isn’t life funny? Two weeks ago I stated my opinion that unit-testing graphical user interfaces isn’t worth the trouble. Now I find myself doing it, writing unit-tests for GUI components.

What happened, did I come to my senses or go crazy (pick the expression that fits your point of view) during Christmas holidays? No, I still think that unit-testing user interfaces is most likely a waste of time, but for some special occasions, like this one, they will pay off.

My task is to make changes to a tool box control in a legacy application. The control is full of application logic and it has a strong and complicated relationship to an edit area control. There are two things I need to do:
First I have to pull out the application logic of the tool box and break the tight relationship to the edit area. Then I need to push that application logic deeper into the application core, so that the tool box could be used via the plug-in framework.

I figured I had two options. I could either refactor the tool box and make the changes in small steps, or I could rebuild the complete tool box logic and then change the controls to use the new programming interface.
I found the rebuild alternative too risky. The code base is full of booby traps and I have to be very careful not to introduce bugs. Therefore I decided to go with refactoring.

But refactoring requires a unit-testing harness, which of course this application doesn’t have. Trust me; you don’t want to refactor without extensive unit-testing, so here I am setting up the tests around the involved GUI controls. It’s a lot of work, especially since I don’t have a decent framework for creating mock objects, but it’ll be worth the effort once I start messing around with the code.

As a conclusion I’d like to refine the “Don’t unit-test GUI” statement to read “Don’t unit-test GUI unless you’re refactoring it, and there’s no easier way to make sure your changes doesn’t break anything.”

Cheers!

Christmas for me is celebration, gormandizing and the joy of happy children. It’s also a time for rest and reflection, and when I think back on this year there is one thing that disturbs me: for me this was a year of us and them.

The company I work for is divided; we have three divisions divided into several so called “functions”, which in turn is divided into teams, where people mostly work – well – alone… And on top of that we have several temporary project organizations fighting for the scarce resources.

Although we’re trying to change things for the better, there is still a lot of distrust and arrogance that stems from lack of understanding between the various formations. We are an organisation that needs more empathy.

My guess is that this is a common problem in our business. We tend to mentally separate us from the others, thinking in terms of us and them. There’s a lot of “those stupid users”, and “management has no clue” kind of talk out there.

We even turn on ourselves. What’s the first thing you do when you look at code that is new to you? I know my reflex is to try and spot design flaws, so that I can point them out. If I can’t understand the code fast enough, the normal response is “who created this piece of crap?”

These responses only show a lack of empathy in the person that utters them. Nowadays I try not to be so judgemental when I look at code that others have created. I’ve come to realize that while there is always a reason for crappy code, it’s never because the programmer wanted to do a bad job. He or she has most likely tried their best, with their current knowledge, or made a deliberate choice, given the circumstances. At least they deserve respect for that.

When we start talking negatively about each other, in terms of us and them, it might be because we lost track of the bigger picture. Here’s an exercise that helps me when I need to put things into perspective. Look at this image from Big Sky Astronomy Club.

The image was taken by Voyager 1 in 1990 on its way out of the solar system. The little blue dot is planet earth. Fellows, that pixel is our home!

In this humbling perspective there is no us and them; There’s only us.

Cheers!

I’m currently rereading parts of the book Test-Driven Development: A Practical Guide, by David Astels. It’s a great book in many ways, well worth reading, but I have objections to one particular section in the book.
The author tries to convince me that developing my user interfaces using a test-driven approach is a good thing to do. I disagree.

I love TDD, it’s one of the most powerful development techniques I know, but it’s not without limitations. For one thing, code with unit-tests attached is more difficult to change. This is often an acceptable price to pay since the benefit of producing and having the unit-tests is usually greater.

But the return of the investment isn’t always bigger than the price, and sometimes the cost of change exceeds the benefit of protection. That’s why most developers won’t use TDD for experimental code, and that’s why I’m not using it to test my user interfaces.

I prefer to develop GUIs in a RAD environment, visually dragging and dropping components, moving them around, exchanging them for others if better ones are to be found. In that process unit-testing just gets in my way. After all, the GUI is supposed to be a thin layer, without business logic, so there is only so much to test.

One could theoretically test that the form contains certain key components, that they are visible, have a certain position or layout, stuff like that – but I find that kind of testing too specific for my taste.

In my opinion, unit-testing should test functionality, not usability. It shouldn’t dictate whether I decide to show a set of items in a plain list or in a combo-box. What it should do, is test that the business logic of my code produce the correct set of items, and leave the graphical worries to the testers.

This brings us to something that is sometimes misunderstood: Unit-testing can never replace conventional testing. Some things are just better left to humans. Like testing user interfaces.

Cheers!

I’m an impatient person, of the kind that are comfortable with making quick decisions on loose grounds, but prepared to change when more information gets available. This attitude has served me well, but also put me in trouble when important decisions were made too hastily. That’s why I always use The Rule of Three nowadays.

I first came across this version of The Rule of Three in Johanna Rothman and Esther Derby’s excellent book, Behind Closed Doors. The idea is to brainstorm solutions to a given problem, and not stop until you have at least three options to choose from. Listing the pros and cons of each solution helps you make a good decision.

With The Rule of Three I’m forced to think broader. I need to widen my view to find possible solutions other than the first that springs to mind. I’ve found that this process makes me explore the original solution better, and the risk of overlooking a good option is greatly reduced. Also, two different solutions can sometimes be combined into a new, even better one.

The Rule of Three can be applied in many ways, within a group or by yourself. It’s a cheap way to build better foundations for your decisions. That’s why I embrace The Rule of Three.

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!
6. Tools of The Effective Developer: Make It Work – First!
7. Tools of The Effective Developer: Whetstones

I just finished reading an interesting post by Ben Collins-Sussman. In an attempt to argue that distributed version control is not the silver bullet, he classifies us and puts us into two groups, which he calls the 80% and the 20%.

The 20% folks are what many would call “alpha” programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. These folks were the first ones to install Linux at home in the 90’s; the people who write lisp compilers and learn Haskell on weekends “just for fun”; they actively participate in open source projects; they’re always aware of the latest, coolest new trends in programming and tools.

The 80% folks make up the bulk of the software development industry. They’re not stupid; they’re merely vocational. They went to school, learned just enough Java/C#/C++, then got a job writing internal apps for banks, governments, travel firms, law firms, etc. The world usually never sees their software. They use whatever tools Microsoft hands down to them — usally VS.NET if they’re doing C++, or maybe a GUI IDE like Eclipse or IntelliJ for Java development. They’ve never used Linux, and aren’t very interested in it anyway. Many have never even used version control. If they have, it’s only whatever tool shipped in the Microsoft box (like SourceSafe), or some ancient thing handed down to them. They know exactly enough to get their job done, then go home on the weekend and forget about computers.

Ben took a lot of heat for his oversimplification. People, it seems, don’t like to be categorized, a fact I too discovered when trying to make a distinction between Developers and Programmers. They especially don’t like to hear that they’re mediocre, not special, or less worth, which is the undertone of Ben’s 80% category.

During my military service I learned that statistically, only two soldiers in a group of eight would be effective in a combat situation. The rest would be pinned down, unable to return fire. Thus, one could say that the firepower of a squad comes from a fraction of it’s soldiers. I think this is often true for development teams as well. A few members are accountable for a majority of the produced value.

The funny thing is, that some of the best value-bringers I’ve met in my career does not fit the 20% alpha-geek group defined by Ben. And many of the “elite” programmers, the ones that do fit the description, have been remarkably inefficient. One reason for this could be that bleeding edge isn’t always the best strategy to achieve business value.

So, the question we should ask ourselves is not whether we’re in the 20%, it’s: Do I add to the firepower of my team? What can I do to bring more value?

When should you start optimizing your system? There are different opinions: Some think you should finish the implementation of all important features before starting the process of tuning. Others mean that this is way too late and instead advocate early optimizations, arguing that it’ll reduce the risk of substantial rewrites later on.

I recommend doing optimizations as late as possible. The reason is that project requirements always change – a fact which seems to be a law of nature – and an optimized system is usually harder to change. Leaving the tuning tasks for later also minimizes the risk of wasting time on insignificant optimizations, that matters little to the performance of the final system.

But dealing with optimizations later does not mean you can ignore performance completely. Remember, failing fast is an important principle of software development, so you want to discover critical performance issues as early as possible. You should therefore monitor performance, starting as early as possible, by creating test cases that provide benchmarks as the system develops. Not only will that give you a feeling of the overall performance of the system, it will also help you measure the effects of your optimizations – when that time comes.

So, Optimize Late but Benchmark Early.

Cheers!

As a programmer you are the ultimate software development tool, and like any tool you need regular care to stay effective. If you don’t invest enough in self-improvement you’ll end up useless, with a blunt sword. I’ve seen many programmers wielding blunt swords, unable to fight their ways out of old habits and paradigms. Don’t let that happen to you. Sharpen your sword regularly.

First and foremost you should take good care of your body. Health is the most important property, and it’s achieved with exercise, nutritious food, and enough sleep; The hallmarks of software developers. 😉

The second most important sharpening activity is constant learning. If we stop learning we become frozen in the slice of time we call life. So try to learn something new every day.

For me, the best way to acquire new knowledge is by reading books. Since I spend so much time in front of the computer screen, a book is a welcome break. I can bring it and read it wherever I want, including the bed and the toilet.

Acquiring knowledge is one thing, making it stick is another. If you want to keep your knowledge for a long time, you should practice. The most effective practice is to teach others what you know. Gather your workmates and hold a lecture, or write about it on your weblog.

If your company allows it, or if you’re lucky enough to have spare-time, make a hobby project. Try to implement something based on your new knowledge. Rereading is the worst kind of practice, but something I resort to sometimes.

My most used whetstones are reading, writing and running a million hobby projects. What are yours? Which ones would you like to have? It doesn’t matter how you do it, as long as you keep your sword sharp.

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!
6. Tools of The Effective Developer: Make It Work – First!

I’ve been thinking a lot lately on the sad state of our business. A majority of software development projects fail in terms of money, time or quality. Why is this so? Why is developing software so expensive and so unpredictable?

Paul W. Homer touches an interesting subject in his post named Repeated Expressions. He means that use cases, test cases and ultimately the source code, are all different ways of specifying the same system. If we could cut down the redundancy, he argues, we would save time.

Others blame the methods we use for developing software. While this is true to some extent it isn’t the whole picture. The C3 project for example, the birthplace of Extreme Programming, were eventually canceled. So even the most agile approach may fail.

No, the main problem is most likely the complex nature of today’s software technology. But complexity is usually a sign of poor abstraction, and this fact has occupied my mind of late. The problem I see is that we are using general purpose languages to create domain-specific applications.

In a GPL we must make all kinds of low-level decisions: how to communicate, how to store the data, how to handle security, etc. We make our decisions based on technology, and once we make our choice we’re usually stuck with it. Wouldn’t it be great if we had a language in which we could focus on the business logic instead, wouldn’t it be great if technology was abstract? That would not only save us a lot of time, it would enable us to exchange one solution for another by running our code through a different compiler.

Is this an unrealistic approach? I don’t think so. The language would have to be domain specific, and you’d have to trade some creative freedom for the increased productivity. But many applications produced today don’t need that freedom anyway. In fact, many applications would benefit from being restricted and having good choices made for them.

Take websites as an example. Most of them have a similar structure, similar ways of communicating, similar ways of storing data, etc. Creating a DSL that would support the basic features of a web page is certainly possible, although you’d probably need pretty advanced layout and graphical features not to impose too much restrictions on the visual design.

The real problem would be to implement the different compilers to support the language. Communication protocols, data storage, formats, security, platform independence, all those things that makes web development difficult would have to be addressed by the compiler. A worthy task indeed, but – as with all complex things – better dealt with in one place. And think of the possibilities it would bring: one could build a compiler that generates an AMP site, one that generates the combination of ASP.NET and SQL Server, JSF, Ruby on rails, you name it. All from the same specification.

Wouldn’t that be great?

Cheers!

I read an article named The Future of Software Development by Alex Iskold. He predicts a future where only a few high quality software engineers will be able to serve the world’s need of computer systems.

With a bit of discipline and a ton of passion, high quality engineers are able to put together systems of great complexity on their own.

The idea is that fewer but more specialized people will be able to do more in less time.

Equipped with a modern programming language, great libraries, and agile methods, a couple of smart guys in the garage can get things done much better and faster than an army of mediocre developers.

I’d like to take this prediction a bit further. Well, quite a bit further actually. I see the extinction of software engineers altogether.

Programming as we know it, is a tedious, highly repetitive and error-prone business. It’s the task of telling the computer how to do things, rather than what to do. In other words: we are still dealing with computers at a very low level. To me, programming sounds like a task suitable for computers.

I see a future where we tell the computer, a kind of super-compiler, what we want to achieve. The input is our specification, and the output is a complete and tested system. All we have to do is specify, verify and then push the deploy button.

That would, using my definition, make us Developers rather than Programmers. There’ll be, as Alex pointed out, room for less and less programmers until they finally face extinction. The last programmer will probably live to see the super-compiler’s AI get clever enough to perform self-debugging and self-improvement. (I didn’t say this was in the near future.)

When I mentally put myself into this version of the future, a part of me protests: Where’s the fun in that? Well, I guess that’s just a sign of wrong focus. That part of me still embrace technology rather than business value.

Cheers!