Since Google's Chrome web browser has been SO much in the news lately, there have been tons and tons of blog posts lately about it. I picked up on this one about the password manager mechanism because well, I am a software developer (er...ok...geek) and I am a bit tired of all of the prognosticating of what Google Chrome means to the competitive landscape of the world wide web.
What struck me about this well written article was how hard it is to communicate to the lay men what is involved when a simple requirement needs to be fulfilled in a software project. In this case: The browser should store website passwords at the users discretion. Sounds simple right? It's not. There are several reasons why.
1) Architectural. Which method shall I use for transporting the request? What storage mechanism will be used? What should happen in the request to store the data fails?
2) Maintenance. How much debugging code needs to be added to each procedure? What debug values would be most valuable when debugging an issue that may or may not be expected?
3) Data. How much info should be stored that is merely related to the task and/or requirement that might assist in management of the application or troubleshooting after the fact?
4) Users. What prompts communicate effectively to the end user that a decision must be made by the user? What prompts or messages impede the user or are effectively not needed nor add to the user experience? If an error occurs, what should be displayed to the user?
5) Developers. Note the (almost) flame war that breaks out in the comments section between developers who either feel the need to point out the obvious, don't like to be corrected, like to correct others, can't stay on topic or will not give up an argument until all parties are not sure how it started.
As you can see, this ain't easy.