Should we stop masking passwords?

Yesterday, the usability guru Jakob Nielsen wrote an interesting article for his alertbox: Stop Password Masking.

Summary:

Usability suffers when users type in passwords and the only feedback they get is a row of bullets. Typically, masking passwords doesn't even increase security, but it does cost you business due to login failures.

In the article, he argues that masking the user password, which has been the standard practice for some decades, is basically worthless and creates usability and security problems (users choosing easy passwords or copypasting them).

He mentions briefly that you could have a checkbox for this, and that for some sites (banks, etc) it might be checked by default.

There are several issues with this:

• Who are you to decide which sites are important enough to have their passwords masked?
• Who are you to decide that in behalf of the user?
• Why do you have to make this a tradeoff, when the code that does the trick is this one-liner?

<input type="checkbox" checked onclick="$('pwd').type = this.checked? 'password' : 'text'"/>Hide password

Give me a reason not to make this the standard design for all password boxes or make it part of a helper script in the browser (i.e. display that checkbox when hovering the password box).

My first Agile experience: Part 1

At my current job, we are using an Agile methodology called Scrum.
It's my first time, and I wanted to share my experiencies.

Cooperation

The first thing I noticed here is the cooperative spirit of the team. Here are some attitudes you will find:

• I have a problem. Who can help me?
• Joe has a problem. Who can help him?
• I will work with Joe.

• Who knows something about technology X?
• I do. I'll do a presentation for everyone.

• We need to implement user story 157. Joe, Can you do it?
• Sure. And maybe Tim could pair with me so he gets a grasp on the YZQ internals.
  

And you won't find any of these:

• Who wrote this crap?
• This isn't my responsibility.
• This has to be done yesterday.
• I don't have time to tell you how to do your job.

We are a Team, with capital T. The success of our team is the success of its people, and vice-versa.

Consensus

Most of us had to work at some point with an arbitrary deadline set by someone that didn't know about the domain, nor the implementation of a requirement. And changing the estimates after beginning the work was out of the question.

Here, instead, the estimates are set by the people who will actually be involved in developing/testing/deploying the solution (the "pigs").
We use a simple yet very effective technique called Planning Poker. You can read about the details, but the things it accomplishes are:

• Order of magnitude estimation that can be refined later, as opposed to an arbitrary number of hours.
• Real consensus based on discussion, as opposed to both imposed times and false democracy (voting).
• Everyone ends feeling comfortable about the allocated time.

Also, nobody will ever force you to work in an area that you hate or have no experience with. Volunteering is the usual way the tasks get assigned.
And you know what? This actually leds people to request to work in those areas!

Of course sometimes it'll be suggested that you work on those items, but not being forced to do that, in addition to knowing that you can always get help, is a big motivator to improve your weak areas.

Communication

The biggest Agile value, as I see it, is focus on communication.
At one of my previous jobs, team meetings were weekly. That mean they would take more than an hour and implied listening to lots of things that were not relevant at the time mixed with all the announcements for the week.

Now, we have several types of meetings. They are done over the phone, sometimes using netmeeting for desktop sharing. This is not ideal, but we are a distributed team.
Our usual meetings are:

• Scrum. This is done daily, is timeboxed to 10 minutes, and everybody says what they are working on (since the last scrum - until the next scrum), and if they have any blockers they need help resolving.
• Iteration planning. This is done biweekly, at the start of an iteration. Not really timeboxed, but it usually lasts 2 hours at most. We decide what user stories will be included in this iteration, and whether we need to do something differently.
• Iteration retrospective. This is done biweekly, at the end of an iteration. It takes 1 hour, and we discuss the learned lessons from the iteration (things to keep, to stop, to try), our current velocity, etc. It serves as an input to the Iteration planning.
• Planning Poker sessions. These don't have a regular cycle, but are done constantly to keep estimates up to date. They run from 30 minutes to 1 hour.
• Tech Talk. This is done weekly and lasts approximately 1 hour. It's used to share knowledge about technology related topics.

Of course, these regular meetings are not the only ones we have. We try to take advantage of all the channels we have available: phone, IM, email, wiki, netmeeting, face-to-face.
Whenever there's something to discuss or clarify, the relevant people are gathered so the unknowns don't pile up.

Conclusion

What's the end result of all this?
Developing some standard enterprise software becomes both efficient and enjoyable.
Who says you can't have both?

Of course, life is not a bed of roses. In Part 2, I'll write about the things that don't seem to work as they should.

How to "sell" Linux to our families and friends

We've all tried telling grandma not to open that attachment, even if the mail "comes from a friend".
We've all fought with Dell drivers.
We've all cried on the inside when dad complains about not being able to find a button in the new version... that was just moved 20 pixels to the right.

When we got tired of that, we tried to get them to install Linux, which we obviously use at home.
Unfortunately, we tend to use the wrong arguments:

• They don't care if "the source code is public and anybody can change it". Even if they know what source code is, they can't do anything with it.
• They don't care about the four freedoms.
• They don't read, nor are they worried about the EULA.
• They don't care about the license prices as long as it comes with the PC (or a friend/relative -usually yourself) can install it for free or a small fee.
  

Instead, try to focus on the things they DO care about.
And don't just talk about it: show them!

• It comes with everything you need (browser, office programs, etc)
• It usually detects your hardware without the need for external drivers (as long as it's supported)
• The media player just works. No need to worry about codecs.
  
• It's easier to find and install new programs. Just open Adept or Synaptic and search for what you need. Image editor? DVD recorder? Poker game? Expense tracker? you've got it.
  
• Also, installing and uninstalling programs doesn't break the computer. Feel free to play.
  
• Pentium II, 256MB RAM? Sure, more than enough for some distros.
• No viruses. No spyware. No calling the tech guy every few months to clean up the mess.
• Yes, you can try it, no strings attached. Here's the Live CD.
• You can run both. You don't need to erase your hard disk, or anything. And you will still have access to your documents. Still not convinced?

You are welcome to comment on additions to these lists.

Google Chrome: the alternative

This is my first post in this blog.
As the name suggests, it's gonna be about development and technology. I hope you enjoy it!

I wanted to begin with my commentary on Google Chrome, the long-awaited alternative to FireFox, Safari and Opera (sorry, I don't consider IE an alternative at all).

Google did the smartest thing for a new application: they designed the solution, but implemented it using existing open source components, thus avoiding NIH and giving back to the community.

Of course, the new browser is not perfect. I used it for several weeks before going back to FireFox, and I had two big reasons for that: Adblock and Atom/RSS support.

Adblock absence is easy to explain: Google makes money from ads, so it would be against there primary interests to support that kind of plugin.

But what about feeds?
I don't need an embedded reader, or "Live Bookmark" support. I use Google Reader for that.
All I need is feed discovery (i.e. show me the feed icon when a feed is available). Is that so hard?

I also miss other not-so-essential plugins, like BugMeNot or FireBug.

Still, Google Chrome gets many things right. I'd love to see a new browser in the near future (1 year?) that combines the best of FireFox and Chrome. The process is easy:

1. Make it simple
2. Make it even simpler. Remove everything that's not essential
3. Allow me to extend it!

Now, what do I love about Chrome?

• The Omnibox. After using it, having 2 separate boxes for addresses and search feels wrong.
• Detachable tabs.
  
• Zero clutter. No menu bar. No fixed status bar. No fixed bookmarks bar. This is very important with wide-screen.
• Automatically adding search engines.
• Startup speed. The cold start times for FireFox are unacceptable.
• One process per tab. Now, a malfunctioning/slow page can't hang my whole browsing session.
• A smart start page. One that I don't want to set to about:blank as soon as I install a browser.
• Fast, fast, fast scripting engine.
• Great in-page search (I belive this comes from WebKit)
• Useful handling of invalid/self-signed certificates. Encryption and trust are two completely separate aspects. It's a shame they are basically tied to each other in the current HTTP implementation.
  

Some things need work:

• Downloading a file to store in my computer is a different action than opening a file with another program (for example, a .DOC or .PDF). Chrome does not make this distintion, and makes me clean the download folder by hand, instead of using a temporary one.
• Popup handling is innovative, but I prefer, to some degree, the FireFox way.

I feel we really needed someone to shake the browser world, and I'm glad it's Google, because it's probably the only player with enough mindshare to drive the change.