Pattern: Orientation

Because of our development process it is easy for us to work on the same project and even the same functionalities with the whole team together. As we explained before we use Stories to categorize and describe the necessary features for a project. Once we start on a story we split it up in tasks. Tasks are simple things comparable with todo's and can typically be accomplished by one pair of designers or programmers working together on the same computer.

Tasks that do not produce actual code, like server maintenance or registering a domain name can be carried out by individuals working solo of course.

Most tasks inside a story will however be development tasks and will be carried out by two people working together using a technique called Pair Programming. Using the orientation pattern it becomes really simple to switch pairs for developers.

For it to work correctly you need to understand about the TDD (Test Driven Development) cycle, here it is;

1. Write a test
2. Make it compile
3. Watch it fail
4. Write a little code
5. Make it pass
6. Refactor mercilessly
repeat until you cannot think of any more tests.

Now stories will typically be split up into tasks, for example:

* Write marketing text
* Design landing page
* Register domain name
* Code landing page HTML
* Submit a form and validate name and email
* Store validated name and email in database
* Submit a form and check if not already stored
* Give AJAX feedback on errors
* Give AJAX feedback on success
* Test in 3 target browsers
* Deploy database, cvs and apache
* Write a blog entry
* Add small advertisement to brains4all homepage
* Write a newsletter article

So you see this story includes a lot of different tasks, not all tasks are Design or Development tasks by a long shot. Still since those are most often carried out by a pair these are the most interesting when you're switching pairs halfway through a task. Let's look at these development tasks:

* Submit a form and validate name and email
* Store validated name and email in database
* Submit a form and check if not already stored
* Give AJAX feedback on errors
* Give AJAX feedback on success

Suppose I've finished with my registering the domain name tasks and I go and sit next to Serge. To help me orientate I can ask these simple questions:

Marko: Hi, what are you working on?
Serge: I'm working on Submit a form and check if not already stored.
Marko: So what are you doing?
Serge: I'm making this test here pass.
Marko: Okay, let's go!

By asking these simple questions I can quickly orientate myself inside the pair. I know what task we're working on in the story, I know in which part of the TDD cycle we are. For me this is enough to be able to dive in almost immediately and add value to the pair.

A funny side effect of this is that a task can be finished by completely different people that started it and almost everybody on the team may have worked on it. This helps to spread knowledge about the system throughout the team and helps you to keep code easy to change. Also by switching pairs frequently I've experienced a much higher sense of accomplishment and team effort. It also helps to keep a lot of energy in the team and if you change pair every 5-15 minutes it helps you prevent those Gung-Ho refactorings that seem to take forever.

What are your experiences with switching pairs?
How often do you switch and how do you orientate?

Our concern for privacy

One question we get from our customers is; “We need to be assured that the information we have on the system will not be shared to others. Do you have a confidentiality agreement for your service?”

I've pasted some paragraphs from our privacy policy, I hope those provide the answer you need;

Brains4All is committed to protecting the privacy of visitors to our website, as well as our account holders and clients. In general Brains4All treats your contact information as private and confidential. Brains4All will not give, sell, rent, exchange or otherwise provide your information with anyone else without your prior consent (except when compelled by law — see below).

Compelled Disclosure

If we are required by law to disclose any information that you have provided us, we will attempt to give you notice (unless we are prohibited) that a request for your information has been made, in order to give you an opportunity to object. We will attempt to provide this notice by email, if you have given us an email address or by postal mail if you have entered a postal address. If you do not challenge the disclosure request, we may be legally required to turn over your information.

What that means in short is that we will not disclose any information in our customers' account without a court order or subpoena, issued under valid Dutch or European law and try to inform you of the fact as well.

Please be advised that in order to ensure the privacy of your data your team needs to connect to the service by secure https encrypted connections.

We understand your concern for privacy and I hope our policy demonstrates our commitment to that. Please write in with any further questions you might have, we're glad to help.

DDP: What is a user story?

We’re starting a new series here on BrainBlog about Design and Development processes here at Brains4All. Hopefully we can share some of our insights with you and maybe you will find it useful. Also for those of you looking to purchase Design or Software Development services we hope it can give you some insights as to what makes a successful project and what to look for in a supplier or a vendor.

This first installment is actually a frequently asked question, we use user stories to describe functionalities and estimate scope of the project. A lot of people wonder why we don’t need big design documents or requirements gathering. Stories are a part of the answer.

Basically a story is a short story, about a paragraph or two, that describes the functionality to be developed. It is kind of like a use case only it does not try to be as complete or technical. A story is just enough text to describe what is needed and to be able to estimate the cost/difficulty and duration of the development. A story does not try to be complete because only in working software can you really see how it works and what it does, and if that is what you really need for your business. What is the value of a piece of software that you never use?

Zero, Zilch, Nada, Nothing.

Why would you pay for something that has no value? That does not make sense.

Developers build what is described in the story and then release it to the development server where the customer can use it to test it out. When you've experienced how it works we hope to get your feedback and use that to improve the functionality in the story. We repeat this process again and again until we get it right, and you're completely happy with the working software that was described in your story.

Basically a story is a guarantee for a customer to be happy with the functionality delivered, regardless of the amount of time spend to get it right.

Brains4All uses a relative system to estimate our projects. We do not estimate in days, hours and minutes but in a unit we call story points. What we're saying is a story with 3 story points is three times more difficult then a story with a 1 story point estimate. We average out how many story points we do in a month as a team and divide the total team cost on that amount. That is how we arrive at the cost of a project and it also gives us an excellent indication of the amount of time we need to complete a story. Of course we make mistakes too, but while we cannot pinpoint the delivery date of a single story, we can guarantee that a whole project will be delivered on a certain date.

As a customer this offers you some advantages:

• It means as a customer, you get the working software on a guaranteed delivery date.
• It means as a customer, you know the total cost for this project to you, for this set of functionality, no surprises, and no late fees.
• It means guaranteed quality of the software.
• It means as a customer, you get the functionality you need and that you're absolutely happy with it, or you don't have to pay. (What? – Yes you don’t have to pay until you’re happy – at least with Brains4All)

It also means to our not so tech-savvy customers (don’t worry – you’re not alone) that they get a proposal that is not swarming with jargon or technical terms they don't understand. Even better, we try to get our customers to write the stories themselves - in their language, so the stories actually mean something to them.

For us as a vendor it means we can offer these advantages to our customers whilst keeping the flexibility we know we need in a software project. By using an abstract unit (story points) to determine scope we have the ability to have the customer change scope mid-project, just as long as the total number of story points stays the same.

As you can understand our development process depends rather heavily on communication with our customers. The speed at which high quality feedback can be given is decisive for project turnaround.

That is why we like to get in touch with our customers first to discuss what is needed. In talking to our customers in the past few weeks I have been very positively surprised in this respect. I've found a lot of excellent communicators capable of producing and getting across needed information almost effortlessly, information that had to cross time-zones, language-barriers and some oceans as well. I guess that in the information age people adapt to embrace new ways to exchange information and they are becoming more adept using these technologies more efficiently. That is why I'm excited about our upcoming projects.

Please let me know how you feel about our story concept and what other questions you might have about our development process.

Simple football

I've been waiting for an opportunity to write about the world championship football wich is taking place in Germany now. First, this is the first WC to be blogged about in this amount. If you want to catch everything there is to know about the WC from a user perspective, (pun intended) check out the SoccerBlog archive. It is a syndication of a lot of soccer blogs, some of which are pretty good. There are even some live blogs from bloggers, blogging about the match as it is played. You'd think there wouldn't be a market, but it seems there is...

One particular post I liked is from Worldview World Cup which talks about the Dutch shirt Design and the changed strategy of the Dutch team.

The Dutch like to play offensive football, they like to be on the opponents half and in possession of the ball upward of 70% of the time. Most teams react to this strategy by calling every man into the penalty area and locking the goal solid.

The Dutch defeated Ivory Coast ... to advance to the round of 16, owing in part to the new Era of Pragmatism in Dutch soccer ushered in by Marco van Basten. The argument for it goes like this: The modern game, with its powerful defenders, does not allow you to practice flashy attacking style all the time. If we'll give up some of the initiative in the match, we will be able to do our gorgeous, uniquely Dutch thing at least some of the time. This strategy is also meant to protect the Dutch from these dull defensive underdog teams that have been so successful of late (Sweden and Mexico are the latest victims, with Portugal well on their way as I am writing this).

Apparently the Dutch Coach is working on a book "The Pragmatic Footballer" and talked to Pragmatic Dave for a bit.

To me, Pragmatism, Getting Real or Simple are all in the same league. Use common sense in design and development, measure results as well as shifting goals, examine and fine tune effectiveness of techniques, review and adapt accordingly.

By getting rid of the Dutch dogma of needing to play beautiful football all of the time, the Dutch create more chances to practice their style when it counts. For now, the Dutch results are accordingly. An example is the record streak by Dutch goalie Edwin van der Sar (see picture) that was ended by the Ivory Coast goal last Friday. Van der Sar managed to keep the nil for up to ten WC games and over a thousand minutes of play, a European record. His unpassable streak has lasted since the match against Finland in October 2004.

So simple works, also in football as well as in development;

Skip the chrome, but make your app shine where it counts.

Under the leadership of Marco van Basten the Dutch team has only lost one match yet, a practice match, against Italy. Coaches are very important to football, well almost any sport. Why are there so few coaches in software and web development?

I think any team needs a good coach. What do you think?

They don't plan for change.

There is an interesting 2^nd 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.

From concept to working software in 10 minutes

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.

Test:
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.

Requirements:
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.

Design:
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 = ‘marko@brains4all.com’;
    $invalidEmailAddress = ‘http://www.brains4all.com’;
    assertTrue($objEmailValidator->validate($validEmailAddress);
    assertFalse($objEmailValidator->validate($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.

Code:
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 == “marko@brains4all.com”) {
                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 = ‘marko@brains4all.com’;
    $invalidEmailAddress = ‘http://www.brains4all.com’;
    $yourValidEmailAddress = ‘blogreader@bloglines.com’;
    assertTrue($objEmailValidator->validate($myValidEmailAddress);
    assertTrue($objEmailValidator->validate($yourValidEmailAddress);
    assertFalse($objEmailValidator->validate($invalidEmailAddress);

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

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

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:

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!

Simple

Companies have words. Teams have words. People have words.

Always one word;

MacDonald’s -> Tasty
Wendy's -> Healthy
37Signals -> Less
Intel -> Processor
Apple -> Usability
Google -> Search

is the Brains4All word.

We have learned the hard way what others have known for decades:

"Keep it simple stupid."
"Do the simplest thing that could possibly work."
"Everything should be as simple as it is, but no simpler!"

Accepting lower quality is not simple.
Ignoring your clients is not simple.
Taking a short cut is not simple.
Skipping a test is not simple.
Being lazy is not simple.

Simple is hard to do.

Simple is more than the sum of the parts.
Simple is elevating the constraint.
Simple is listening to your users.

Simple is talking (and listening) to each other.
Simple is always adjusting course.
Simple is doing one thing right.

Simple is looking back to see what went right.
Simple is think-plan-do-review.
Simple is sharing feedback.

Simple is software that works.
Simple is intuitive usability.
Simple is pleasing design.

Simple is craftsmanship.
Simple is having values.
Simple is respect.

Simple is powerful.
Simple is simply human.

Simple is what makes Brains4All products unique. While there may be complex technology at the core of the product, the end result is always the simplest thing that could possibly work for you.

Simple applications that give you what you need and help you get the job done. Simple tools that help you get paid.

We are Brains4All, proud to be simple.

Fixed Everything

There was some talk over at Signal versus Noise about trashcan deliverables. I find their blog interesting and very recognisable.

We’ve been doing Fixed Everything contracts for a few years now and with astonishing success. Our proposals have become our number one unique selling point. Clients adore our proposals and we often find them inquiring how we do it. And Jason is right; Happy clients all around.
We’ve developed a way to estimate functionality that is congruent throughout projects. That enables us to fix time, budget, scope and quality in the contract. (Well we have only one level of quality: The Highest. Well, there is another level of quality, but that’s only used when people’s lives depend on the software…)
We guarantee on-time, on-budget delivery of the project. If we’re one day late, the customer does not have to pay. If we go over budget, it is our problem. It won’t cost the customer one penny more. We guarantee the amount of scope we produce. Furthermore, the customer can stop the project at any time.
Flexibility or agility is retained because:
• If the project is finished and there is still value to be delivered, the customer can start a new project delivering that value.
• If during the project the customer finds his priorities have changed, the customer can exchange functionality. (ExChange Request) i.e. Take out the same estimated amount of functionality and replace it with something more valuable.
• Progress is measured in Delivered Working Software.
• Customer cannot exchange delivered functionality.

Amounts of documents for the customer to sign: 1 Contract
Happiness level of customers: 3E (Excited – Elated – Ecstatic)

Be sure of one thing: Keep your promises. If you do, your earn trust. Still you can only earn trust if you trust yourself and abolish fear. Having dozens of documents to sign or trashcan deliverables is a clear sign of lack of trust, either in yourself or in your relation with the customer. Customers need to learn inside a project too. We’ve never finished a project with the exact same functionality that was in the contract. Still all our customers are references. So it can be done and we have been doing it long since we ever heard of 37signals or Getting Real. We’re just glad to see others doing it as well. We hope you do it too.

@Rachel: Drop that project. If no one is willing to invest time to be a decent customer there is no value in your project. The only way to provide value is to drop it. Instant value;

• Less loss of resources on something nobody wants or believes in
• Less frustration for you and the team
• Less documents
• Less paper
• Less trees killed

Everybody profits!