BrainBlog is the Brains4All weblog. Established 2004 in The Netherlands. Brains have been working in IT since 1983, working on the internet since 1993, and using their own agile development process for design and application development since 2003. We talk about about design and usability, the industry of software and web development, web applications and simplicity, beautiful and spectacular things.

Sales day

May 31, 2006 |

Today is sales day. No particular reason. There never is :)

I was talking to some of our friends in Philadelphia. Nick Bertolino and his team are hard at work on a web based application that can help you manage your sales process. I’ve been helping them out with usability consulting. While I’ve spend only a small amount of time on the project, Nick and his team were able to make great progress in the past three weeks. As always it is important to focus on simplicity; the way your application will be used and by whom. What I like about their application is how they’ve targeted a wide market with a niche product. Nick and his team say they could use some help with beta testing so head over to and click Sign Up.

As Nick and myself both have backgrounds in sales, it was fun talking shop together. While we were talking I came across Eric Wolfram's Writing, How To Sell -- Converting Leads from your Sales Pipeline.

Eric has some great tips to help you qualify your sales pipeline. While most of his sales books taught him to not close over the phone or through email and always meet in person, he’s had so much success; he’s reluctant to change that.

Still he sends out a lot of proposals and between 30% and 50% of them close. What a waste of time on those unclosed proposals! So to help qualify active leads and reduce effort on writing proposals Eric has started asking for meetings with his leads. He’s found that 95% of the leads that are willing to meet him, willing to make an effort close by the end of the meeting.

A similar technique that works well is called “Bargain for access to power”.

All prospective companies will at some point in your sales cycle want you to write a proposal. Writing proposals costs you time and effort. If you agree to write a proposal say that you feel it is fair that if you invest time and effort on writing a proposal, it would only be fair to receive something in return for your efforts. 99% of prospects will answer this question with:

“That sounds fair. What are you thinking of?”

Ask for an opportunity to talk to the person(s) in power, someone in the organisation that is empowered to make a buying decision, like the CEO. If you put in the time and effort to write the proposal they want, do you think it is fair you get a chance to present it to senior management?

Most prospects agree to have you see the “Big Boss”. This keeps you in control of the sales process, as opposed to sitting idly by the phone as they are giving your proposal “serious consideration”.

Using this technique, you get to stand by the prospective buyer to pitch his idea to senior management. All clients are apprehensive of this. It means you’re not trying to sell them.

You’re helping them buy.

Hey, you can be a buying consultant!

Ps. For more sales tips checkout the Think Pipeline Blog where Nick has some wonderful sales tips for you.


10 rules of user experience

May 20, 2006 |

I found this great list on ACM Ubiquity.

1) More features isn't better, it's worse.
2) You can't make things easier by adding to them.
3) Confusion is the ultimate deal-breaker.
4) Style matters
5) Only features that provide a good user experience will be used.
6) Any feature that requires learning will only be adopted by a small fraction of users.
7) Unused features are not only useless, they can slow you down and diminish ease of use.
8) Users do not want to think about technology: what really counts is what it does for them.
9) Forget about the killer feature. Welcome killer user-experience.
10) Less is difficult, that's why less is more.

While I don't agree with all points, it is a great article and has some lessons for all of us.


They don't plan for change.

May 18, 2006 |

There is an interesting 2nd post on Bokardo about reasons why web based applications fail. One of them is a central problem in software engineering today. They don’t plan for change.

One of the most common battle calls of web developers these days is that you have to plan for change. One certainty is that the app you’re working on right now isn’t the one that will be there a year from now, a month from now, or even a week from now. The software cycle is speeding up. And interestingly, it isn’t just the new, small web apps that lead this charge. It’s Amazon, Google, and eBay, who have such sophisticated backends that they’re able to manipulate, test, and retest different features
on the fly to a subset of users. They didn’t get to where they are today by coming up with a fantastic initial design that “just worked”. No, they’re tweaking, tweaking, tweaking while you and I sleep.

Brains4All is not only planning for change, we are actively embracing it. There are three things certain in life: Death, Taxes and Change.

But change is difficult, and there will always be resistance and inertia. The best way to cope with change is to make change itself the routine. Change all the time, by default.


A message from a client

May 15, 2006 |

Hi there,

Just wanted to say that I’m liking your service so far, and the way you have set up the customization and labeling of categories/sub categories is brilliant and the best move you could make. Here has been my experience after a couple days:

The stopwatch is a handy feature, but can easily disappear by accidentially closing it or navigating away. I recommend making a pop-up window for the timer which would be more accessible and would be less likely to close by accident. ;)

Other than that:

Set-up was fairly easy
The site runs smoothly and seems intuitive
The interface is clean, although some of the imagery used is a little cliché
The ability to configure & label categories, & configure billing rates makes it more flexible than your competitor

Like MickeyD’s – I’m lovin’ it!

Brian J. Collins
Stickstone Design

The stopwatch continues to run if you accidently close the site. Just go back in and you'll find it is still running and keeping the actual time. (Marko)

Brian goes on to report his findings in more detail over in the comments of our original beta review at TechCrunch. Brian, thanks again for your wonderful feedback. If you've got something to share, we'd love to hear about it.


From concept to working software in 10 minutes

May 12, 2006 |

So if testing is a good thing, why not test all the time? In fact, why not start out with testing?

If you have a large stretched-out project with a fair bump of testing on the end, we’ve seen that often the testing phase will be pressured because of the deadline. What is even worse is that the valuable feedback from the testing phase will have no way to be incorporated into the design and code of your project.

We’ve seen that to accommodate learning in a process we have to make it iterative and build in practices that facilitate and encourage learning.


Think about your goal, what it is you are trying to achieve. Keep your large goal in mind but as small goals are easier to achieve then large goals, focus on a tiny subset of the problem. Choose the tiniest subset that will bring you the closest to the great goal when implemented.
Now figure out what it would look like when your tiny subset if finished. For instance; a customer enters a valid email address. Think of some test cases for it.
• User enters a valid email address -> test passes.
• User enters an invalid email address -> test fails.

Quickly think of the requirements that you need to implement this subset of functionality. You need to know what makes a valid email address and you need to have an email address to validate.

As you have thought briefly about your test case you are now ready to do the design. You do the design as you type up the test code:

    $objEmailValidator = new emailValidator;
    $validEmailAddress = ‘’;
    $invalidEmailAddress = ‘’;

Apparently we are going to need some object to house our validation routines, it has a method called “validate” that you pass a single string value: the email address to check. In this case it passes in our valid email address.

Now write just enough code to pass the test. Nothing more. Don't create stuff you might be needing later. Just the code to pass the tests:

    Class emailValidator {
        function validate ($emailToCheck) {
            if ($email == “”) {
                return true;
            } else {
                return false;

Run the tests, if and not until all the tests pass you can check it into the versioning system, from where it can be released as working software.

That’s it; you’ve written your first test in an iterative manner and released your first working code for your customer to review and to bestow feedback on.

But wait!
How can you be serious? The code above only checks to see if it is your email address that was entered. What if I entered my own, the test would surly fail but my email address is definitely valid as well.

Well, let’s try it and add another test. Remember this is an iterative process.

    $objEmailValidator = new emailValidator;
    $myValidEmailAddress = ‘’;
    $invalidEmailAddress = ‘’;
    $yourValidEmailAddress = ‘’;

If we run the tests, the new test fails miserably. You’re right. You have to change the code to make it pass:

    Class emailValidator {
        function validate ($emailToCheck) {
            if (preg_match("/^[a-z0-9_.-]+@[-.a-z0-9]+\'.[a-z]{2,6}$/i", $emailToCheck) == 1) {
                return true;
            } else {
                return false;

If changed the code to have a simple regular expression match. Let’s run the tests again. Hey, the tests pass; quickly check in your code to be delivered to the customer! Can you think of a test to break the code?

Repeat until you can’t think of any test cases, or your test cases stop being sensible or relevant. Move on to the next tiny subset of functionality you need to implement. Be sure to talk to the customer about the software you’ve made. Find out how he likes it and to see if any improvements can be made. Does your code address what the user needs?


Not Science

May 11, 2006 |

Developing software is a learning experience. It is about the customer and the developers learning what the customer really needs. Not until after the customer gets to use the product will he have the experience of how it is going to be, using this product. By using the product the customer will find out more about how it will help him.

Developers need to learn about the customer’s business. They need to become experts on the customer’s domain and be able to implement a solution in that domain in the time span allotted to that particular project. Furthermore they need to already be craftsman in their own expertise; Delivering valuable software that works.

There are a few things necessary for learning:
• Information or domain data; instructions
• Experimentation or application of received techniques and data
• Gain feedback on performance
• Think about performance and plan to improve

To accommodate for learning one would like to have a software development process that supports the necessities for learning. Developers would like multiple instances of receiving information, with increasing difficulty as one grows in the domain. You would like to be able to experiment with applying the knowledge and receive feedback upon how well you performed. After that you’d like to think about how you can improve your performance and then have another go at it.


Think – Plan – Act - Review


When people like what you do

May 10, 2006 |

There has been some brilliant feedback on the release of 14Dayz online time tracking last week. Here's the story from Brandon Watts that he's posted in his Blog:

14Dayz is simple online time tracking that won’t make a mountain out of a molehill. Whether you're self-employed, a boss, or an employee, the service has something to offer you. Creating and managing your projects is easy enough, and once you invite your team members to participate, things should start to run like clockwork. Time is reported by client, task, and description, so there's no doubt as to what's been going on. Reports can then be printed and exported for your company or client so that you can present thorough data about where the time has gone. Various pricing plans exist, but you can enjoy some of the core features for free.

Read the whole story about 14Dayz.


Testing is good?


We all agree that in software development, testing is a good thing. Then please tell me why testing is always pushed to the end of the development cycle where it runs the highest risk of being cut or obliterated by the ever on-coming deadline?

This is the plan:


Then reality happens:




May 4, 2006 |

Good news for all Dutch 14Dayz fans. Today 14Dayz was released in Dutch as well. We still have some work to do on the web site, but the application is available completely in Dutch. Just choose your preferred language on the login screen and the application will be automatically translated. If you spot any mistakes, please contact the team at Also we would like to get in touch with volunteers who can help translate to other languages as well. Translations of the application are done in a simple text file that we email you. Let us know if you'd like to help translate and into which languages.


14Dayz is live!

May 1, 2006 |


14Dayz is the simple online time tracker. 14Dayz makes time tracking simple for teams, life hackers, contractors and freelancers. 14Dayz ends the hassle you have with your current time registration solution. If you get paid by the hour, you need 14Dayz. Check it out now, go to:

You don't need to install anything, 14Dayz is entirely web based. All you need is a web browser and an Internet connection. You can access your time sheet wherever you are, at work, at home, at a client or on the move. Don't worry, we take good care of your data, you can use encryption to secure your data as you send it over the line* and we have extensive back-up strategies to keep your data safe.

Keeping track of your valuable time can't be simpler than with 14Dayz:

. Organize your work
. Invite your team
. Track time
. Report hours and cash

With 14Dayz you can easily:
. Log hours
. Create specifications
. Get paid

Enhanced features include:
. Measure progress against a project budget in time or money.
. Have separate rates for team member's projects, clients or types of jobs.
. Customize the vocabulary to match your own.
. Real time tracker helps you get rid of guess work at the end of the week.
. Create reports and export them to PDF or Excel*.

*Only available on some paid plans, view a plan comparison:

Try 14Dayz now for free, sign up for a simple free plan or evaluate a paid plan free for one month. There are no long term obligations, just pay on a month-to-month basis for what you really need. Upgrade, downgrade or cancel your plan at any time. If you cancel or downgrade back to the free plan, you won't be billed again.

So sign up now and get rid of today's time tracking hassle. Try 14Dayz now for free. Please go to

Just email if you have any questions. Thank you for signing up and we hope you will share your experiences with us.


14Dayz goes live today


We still have some minor issues to tweak but we will be going live later today. Check out When we go live, beta testing officially ends and you can no longer sign up for the discounted beta plans.


Brains4All Hosting Dutch XP User group meeting tomorrow



Everyone is invited to join us on the Dutch XP user group on Tuesday the 2nd of May. We're hosting this months meeting at our offices in Kamperland. You can get a bite to eat, talk shop, exchange ideas and experiences with others and meet the team of course. You can even set the agenda yourself by suggesting interesting ideas. Please Sign Up here by editing this wiki page and adding your name to the list. See you tomorrow!


Archive entries



Sign up today