Philippe Starck: Why design?

Jacek Utko: Can design save the newspaper?

Paul Bennett: Design is in the details

David Kelley: The future of design is human-centered

Stefan Sagmeister: Yes, design can make you happy

Janine Benyus: 12 sustainable design ideas from nature

Jared Spool: Journey to the Center of Design

Bonnie John: Usability and Software Architecture: The Forgotten Problems

Bill Scott: Bringing Design to Life: What Every Designer Should Know about Interface Engineering

10. “That’s weird…”
9. “It worked yesterday.”
8. “It must be a hardware problem.”
7. “What did you type in wrong to get it to crash?”
6. “There is something funky in your data.”
5. “You must have the wrong version.”
4. “Somebody must have changed my code.”
3. “Did you check for a virus on your system?”
2. “You can’t use that version on your system.”
1. “IT WORKS ON MY MACHINE!”

–
Photo courtesy of agea_blog.

You don’t have to agree with all of them — just be aware of their influence.
– Obie Fernandez, author of The Rails Way

• Developer motivation and productivity trump all other factors for project success.
• The best way to keep motivated and productive is to focus on delivering business value.
• Performance means “executing as fast as possible, on a given set of resources.”
• Scalability means “executing as fast as needed, on as many resources as needed.”
• Performance is irrelevant if you can’t scale.
• If you can scale cheaply, milking every ounce of performance from your processors should never be your first priority.
• Linking scalability to choice of development tools is a pervasive mistake in the industry and most software does not have extreme scalability requirements.
• Performance is related to choice of language and tools because higher-level languages are easier to write and understand.
• There is wide consensus that the performance problems in most applications are caused by poorly written application code.
• Convention over configuration is a better way to write software. Huge XML configuration files must be eliminated!
• Code portability, the ability to take code and run it on a different hardware platform, is not particularly important.
• It’s better to solve a problem well even if the solution only runs on one platform.
• Portability is irrelevant if your project fails.
• Database portability, the ability to run the same code on different relational database systems is rarely important and is almost never achieved.
• Presentation is very important, even for small projects. If your application looks bad, everyone will assume it is written badly.
• Allowing technology to dictate the approach to solving a business problem is usually a bad idea; however, that advice shouldn’t be used as an excuse to stick with inferior technology.
• The benefits of generalized application components are dubious. Individual projects usually have very particular business needs and wildly different infrastructure requirements, making parameterized reuse very difficult to achieve in practice.

From the book The Rails Way by  Obie Fernandez.

• OpenID background. what it is and why you would like to use it.
• OpenID consumer implementations made easy in Merb & Rails
• The hard part: Testing the damn thing, and why mocks won’t do it.
• Introducing ROTS (Ruby OpenID Test Server)
• Live Code
• Q&A

The speaker for the night is Román González.

When:  Mar 23, 7pm
Where: WorkSpace 21 Water Street, Vancouver

Update:

[via IT World Canada]

If it works without tests, it works by accident.
– Brian Liles

Test All The F***in Time Brian Liles
Test All The F***in Time  is a passionate talk on testing by Brian Liles. Though the presentation was made on a Ruby conference (Ruby Hoedown 2008 to be exact), the principles he shares with the audience are very much applicable to anyone working on code.  You can view the full presentation here.

Manager’s Introduction to Test-Drive Development
This presentation is a primer for managers who want to understand the value of TDD. The talk was given by Dave Nicollete and Karl Scotland. You can view the full presentation here.

How I Learned To Love Testing by Gregg Polack
Gregg Pollack is one of the guys behind the Rails Envy Podcast fame and an active member of the Orlando tech community.

Video courtesy of Levy Carneiro Jr.

When Do I Test?
If you are still not sure, please visit this website.

[via Mike Dillard's Newsletter]

A usability test can be as simple as grabbing the next person that passes by the hallway. You don’t even need a hundred people; five people is enough.

We conduct usability tests because we know that someone with a set of fresh eyes will find more problems in the application than someone who has been looking at the user interface everyday for the past 189 days. When we ask people to participate in our usability tests, we expect them to be super-critical of our software. We tell them we’re evaluating the software, not the person. It is absolutely OK if they tell us that the “interface sucks” or “I felt dizzy after looking at this page. I think I’m gonna puke.”

But as experienced by Jensen Harris, a Microsoft programmer working on the Office software, people tend to become less critical during usability testing as if they are suffering the Stockholm syndrome — a case where the hostage becomes sympathetic with its captors. Why does it happen?

It’s human nature

If someone invited you over dinner and asked you what do you think of the food you won’t say it tastes bad. You will most likely say, “I love it” or “you should start a restaurant business.” It is our human nature not to say bad things of a person especially if we are in her house. Probably after the usability tests, you would tell your friends that the new software Greg is working is a mess, but not infront of him.

We think we’re computer illiterate

When we were kids at school, if we’re the only person who got the division wrong, we feel very bad. Can’t blame you. The other kids would probably be laughing and by now you think you’re stupid. Add the look in your teacher’s face as if telling you to pack your things, go home, and sell banana. Growing up, we were conditioned that if you don’t get it, it is your fault. Every time we can’t figure out how a software works, we tend to blame ourselves, rather than the software, because we think we are “computer illiterate.” If only we could adapt to this software, then there wouldn’t be any problems.

So what can you do?

• Be friendly. It’s difficult to tell the truth if someone would kill you by doing so.
• Reassure the participant that this is not about her, this about the software.
• Be always on the lookout. If the participant appears hesitant to comment, help her speak out like asking questions such as “Do you find the text confusing?”