Email address – Wikipedia:
Some mail services allow a user to append a tag to their email address (e.g., where firstname.lastname@example.org is the main address, which would also accept mail for email@example.com or firstname.lastname@example.org). The text of tag may be used to apply filtering and to create single-use addresses.
I see developers get this one wrong all the time. And, actually, they don’t get it wrong: they copy someone else’s regex or validation method, and never bother to test it. If I’m filling out a form online, I’m probably going to give you my Gmail address, and I’m probably going to inject “+yoursite” before the “@” symbol. That helps me track who’s abusing my trust.
But: you have a requirement to “reject” invalid email addresses. What’s a valid email address? Well, to get completely pedantic, lots of things are technically valid email addresses that you’ll never run into. This is one of those cases where I’d actually rather see a set of tests — good emails and bad emails — rather than a “requirement” (“email should be valid”) or the specification itself. (Are you doing anything useful with that email address? Are you confirming that it belongs to the user? Because if you can’t answer those questions, a vague requirement about “valid” emails is just a distraction.)
Truly, the requirement should be based on the audience and expected input. Are you creating a site where people might be typing in their username rather than their email address? (Do your users confuse their mailing address with their email address?) Protect yourself against the scenarios you’re likely to run into, and then pour your energy into other ways to make your form better. (Not writing the fix for the edge case that means
an.”unusual\ example”@clownpenis.fart doesn’t pass, because I guess it’s a valid email address.)
A friend wrote to ask “what are ten questions you ask at the start of a project?”
My jobs, over the course of the past few years, have let me work more directly with people at the start of the process, so this is a question that I’ve thought about a lot. (Over the course of the years, I’ve started and refined a document that eventually numbered 48 questions, so I’ll have to make my questions here count.)
What Do You Know?
First off, no set of ten questions is going to work for everybody, all the time. I’ll focus here on custom software development on the web, but even that’s different than it was five years ago. Today, you’ll want to ask questions about how the development effort integrates with mobile strategy and any social media presence. (Both of these things would have been intriguing and futuristic until somewhat recently.)
The Questions, Already
- Where are you at in your process? It might be that the client has the website totally mapped out, wire-frames wire-framed and servers procured. It might be that the customer just has an idea, and needs help with strategy, design, content, and analytics. If you ask, you’ll get an answer, even if the response is “huh?”
- What decisions have you made about technology? Sometimes a project is really complicated because of a technical decision or legacy system that was made before you got there. Maybe it’s gotta be done in Plone (you know, Plone, the CMS that’s built on Zope).
- What’s going to happen after the site launches? What is the customer going to do with their new / relaunched site? Are they expecting to see orders roll in? Are they going to want to change content? Are they planning on a phase 2 after phase 1 is done? That changes not just the complexity of the development scope, but the planning, too.
- Roughly, how many pages and templates are we talking about? This is the start of nuts-and-bolts web stuff. (Swap this out if you’re building something else.) This is really just for a sense of scale. Sometimes you’ll hear “I can’t tell you right now, I don’t know” and what they mean is “it’s either 7 or 8, depending on what Gary decides”.
- How should this behave on mobile browsers? The answer to this might really surprise you. They may have decided that they can forget about old phones, or it might be that the CEO has a BlackBerry, or it might be that they’ve never really thought of that. On the other hand, they might say “yes, pixel-perfect, across every browser”, and at least you know what you’re dealing with.
- Are there internationalization, accessibility, or regulatory challenges we should be aware of? You want to expose multi-lingual stuff immediately. Otherwise, you just want to know if you’ll be working in a space with a special-needs audience or government oversight. This can triple an estimate of effort.
- What kinds of interactions, customization, or membership do we need to think about? If you’re talking websites, it’s pretty clear that there should be N pages, utilizing M templates, and some kind of navigation that ties them together. But does the site support search? Contact Us? Some kind of calculator where you determine what your mortgage insurance is going to cost? A marketplace where people shop for insurance? You’ll want to know.
- What other systems does this site connect to? Maybe the most important question. Generally, I hear “none, no other system” and then I ask about Google Analytics. That’s a system, and the clients will be interacting with it (unbeknownst to them). And email — does this system kick off emails at any time for any reason? That’s another system.
- Who’s going to do what, now and after the development? Maybe this isn’t relevant everywhere, but sometimes you’re selling development. Sometimes you’re selling a team, and sometimes you’re selling an entire project. So, do they have PM and QA representation they’re bringing? Will you be working with an onsite IT team to deploy, or will there be a fierce rivalry between your team and theirs?
- When are we starting, finishing, and getting paid? I sometimes leave this for other people to ask and sort out, but these details have to be asked at some point. A word of warning, here: they’ll always say “we don’t know what this should cost, you tell us”. No real project doesn’t have a timeline / budget. (Or: if you have to ask, you can’t afford it. In my experience, this is unfortunately always true.)
Moving Beyond the List
The script above evolved over the course of years. Some questions worked, other questions turned into others, and some questions never got me where I wanted to go (so I don’t include them above). If you don’t write this stuff down, you minimize your chances of evolving and improving your process. (It’ll evolve, I guess: randomly. Wildly. Aimlessly.) Give your list of questions some careful consideration after each interaction, and you’ll be naturally drawn towards making it better.