Cykod Web Development and Consulting Blog

Ring! goes the phone with a certain noticeable urgency. You reach over and answer it with some trepidation.

"We've got a great project" says the breathless client, "but we need to quote it today and it's gotta get done in the next two weeks!"

Looking over your schedule you think, "We'll I can push this here and this there and I think I can get it done"

"And how much?" asks the client

You crunch some numbers and they come out too high - you only have two weeks after all, so even with the rush fee you can't charge them that much more than two straight weeks of time, right? So you fudge the numbers, tell the client that you marked some features as "we'll get to them if we have time" and make the price tag 2 weeks of your company's time.

...Two Weeks later...

You've been at the office every night until 11 including the weekends. You busted your butt, but guess what? It got done. It's a little rough around the edges and you didn't get to any of "nice to have" features, but you snuck it in before the deadline and it even has some decent test coverage. A couple of your other clients are pissed off because you've been a little less than normally responsive but you'll have plenty of time to take care of them now that this is done.

Ring! goes the phone, a little too perky for your current state.

"Great news!" says the client, "The boss is out of town so we can't launch for another two weeks. He took a quick look at the project last night though and has a bunch of changes. We need to put in those features that said you would get to if you had time. Now you have time."

Crap.

This story in some form has happened to me more than once and has made be realize that often *urgent* client deadlines are closer to preferences than actual stop-dead dates. Don't let the prospect of a filled schedule and a quick buck convince you to make decisions regarding schedules, features and prices that you normally wouldn't. Stick to your guns and make sure the project works for you. Otherwise the project may drag on and you'll end up burnt out, having neglected your other clients and still have weeks to go on a project that you underquoted. We're still happy to do the occassional rush project, but the same rules apply as any other project.

I read a link on proggit that freaked me out a little bit: A New Law Could Change the Way You Build Database Applications. It talks about a new law 201 CMR 17.00 (PDF) applicable to the storage and transmission of Personally Identifiable Information of MA residents, here's a quick paragraph from the article:

Here are the basics of the new law. If you have personally identifiable information (PII) about a Massachusetts resident, such as a first and last name, then you have to encrypt that data on the wire and as it’s persisted. Sending PII over HTTP instead of HTTPS? That’s a big no no. Storing the name of a customer in SQL Server without the data being encrypted? No way, Jose. You’ll get a fine of $5,000 per breach or lost record. If you have a database that contains 1,000 names of Massachusetts residents and lose it without the data being encrypted that’s $5,000,000. Yikes.

Crikey, I thought. We're screwed. Every time you store someone's name in your database or transmit it over the internet it's got to be encrypted? That can't be right. Facebook would be shut down pretty quickly unless they started serving every page over SSL. What's Mark gonna do?

So either the Massachusetts legislature has a serious gap in understanding or that article is a little more huff and puff than fact. Turns out the latter is true. A commenter on reddit put this in its place as FUD.  I pulled up the PDF (linked above) to the law and took a look for myself to double check:

Personal information, a Massachusetts resident's first name and last name or first initial and last name in combination with any one or more of the following data elements that relate to such resident: (a) Social Security number; (b) driver's license number or state-issued identification card number; or (c) financial account number, or credit or debit card number, with or without any required security code, access code, personal identification number or password, that would permit access to a resident’s financial account; provided, however, that “Personal information” shall not include information that is lawfully obtained from publicly available information, or from federal, state or local government records lawfully made available to the general public.

The law actually makes sense. First name and last name in combination with some very specific pieces of information that you shouldn't be storing anywhere near your Web app in any case. It's still going to be a pain for companies who use your SSN that shouldn't (I'm looking at you Comcast, Verizon, NStar, etc) so that actually makes me kinda happy. Those are the sorts of companies whose employees lose laptop worths of data on a regular basis.

End result for us? Eh, nothing to see here, carry on...

As developers we spend a lot of time coding versus nailing down requirements. Probably 20-1 or higher if you're a developer in the trenches getting handed specs from higher up, maybe 10-1 if you're managing the development top to bottom. When something gets built wrong a lot of times it's a waste of a good number of hours of development time that could probably have been fixed with a couple more minutes diving into the client's head a little more deeply. I need to pinch myself occasionally to remind myself to clarify issues ahead of time rather that after the fact. The main problem is developing is fun. Nailing down specs during client meetings and calls is not.

Just something that popped into my head again (talked about previously in Specs: the Consultant's McGuffin) after reading the Texas Woman's House Demolished By Mistake on the Consumerist.  I'm guessing demolishing a house isn't easy. Double checking that you have the right house listed on the job sheet is a lot less effort in comparison even if it's not quite as fun as just firing up the bulldozer and taking down the first residence you see.

So I had an idea yesterday evening for a way to winnow the field of potential candidates for our next web developer position. Unfortunately we're probably not going to be hiring for the next 6 months or so and chances are I'm going to forget about it, because that's what I generally do.

So instead, this time I figured I might as well write a blog post about the idea and hopefully the pain and suffering caused by random individuals commenting on how awful both the idea and I am will sear it into into my brain so that it'll be available for recall when I need it. So here it is:

The next time we need a web developer instead of requesting resumes by email we're going to create a simple web page with a couple of fields of information and a resume upload (I know it's horrible, the real form would look nicer):

Simple enough, right? Except when a user correctly fills in all the fields and presses submit they will be presented with:

Now, what kind of Web Development company can't even handle a simple resume web form? I don't know, but I'm guessing that most users will press back and try to resubmit their resume. They will again be presented with:

Now I'm guessing that we'll probably lose a huge chunk of potential applicants by this point. And that's ok - from my very brief hiring experience the percentage of applicants who are just using you as a resume dump and couldn't care less about your company in particular is pretty high. Anyone who's really interested in the job but stymied by a couple of simple 500 pages and doesn't feel any impulse to hack ain't what we're looking for. These are web developers after all, and the best of them have certainly hacked their way around a website bug or two.

For the remaining 5%, maybe, just maybe they will press back one more time and take a look at the HTML for the form they are submitting. If they do that, there it'll be, plain as day:

<input type='hidden' name='resume[CauseInternalServerError]' value='1'/>

If they are a web developer worth their salt, they will open up Firebug (extra points for using Curl - we'll look at the User-Agent), POST a '0' instead of a '1', resubmit the form and be greeted with:

"Well played sir or madam, we should be contacting you to set up an interview shortly"

And there you have it, a pre-selection process that values motivated, out-of-the-box problem solving and a small modicum of Web knowledge. What more could you ask?

P.S. if anyone has used or uses anything similar to this and it worked and/or blew up horribly, I'd love to hear about it. We're probably not going to do this exactly as describe because I'd feel guilty about potential pain, suffering and frustration caused but I think we will try to do something at least slightly odd.

Addendum #1:  One idea from below that I like for how to fix this would be to return a fake status (but still show same error message) that Jim wrote:

While it's true, only strong candidates will succeed I think a lot of people will assume you have no respect for quality and leave for that reason. I think you should make the error more clear. Something like "Error 550: This is not really an error, it's just a riddle."

Addendum #2:  Lot of good ideas in the comments - I think if we were to implement this I'd probably take "Bronson's" advice slim down the form (All that info is on the resume after all) and add a little bit of text as some people have suggested to give people the idea that some game is afoot here:

After all,  I think most people might miss that line of text the first time around, but after getting an error message and pressing back they might take the time to read a little more carefully, and that sentence sounds a bit odd to include on a form that is clearly not functional (and only has 1 field).

When developing a web app, your app's capabilities are far more important than it's features. Aren't they the same thing? Not in my mind: a capability is something you can do with the product while a feature is something a product can do.

Capabilities are awesome. Features for features sake suck.

The first iPhone was a hit because even though it lacked in the feature department (No 3G, MMS, etc) it let people do things with their phone they couldn't or wouldn't have before. Same with the first iPod. In what has to be one of the funniest-in-retrospect single line reviews of the first iPod, alpha-geek CmdrTaco, the creator of Slashdot wrote:

No wireless. Less space than a nomad. Lame.

He couldn't have been more wrong. We as geeks tend to focus on the features because we think they are important to us, but the truth is that we are users too; what we can achieve with something is orders of magnitude more important than what the product itself can do.

The good news is that there seems to be a strong trend in software development to focus less on features first and rather on user stories.

On of the nice things about user story driven design is that you say "A user should be able to do YYY" and then figure out the simplest way to make that happen.

Feature driven design might say "we should have a web 2.0 interface" and so you spend two weeks creating the perfect developer framework for whatever web 2.0 means - and then the minute you try to add in an additional capability into the site you realize your framework doesn't support what you want to do. It's true at launch time you will get to check the checkbox "Web 2.0" on the back of the metaphorical box but all you really ended up with is code that will need to be supported but isn't at all essential to your users.

Microsoft word is the starkest example of this I've seen. The hell that the Microsoft programmers must go through supporting all the features that no one uses must be a very dark place indeed. I need my word processor to have a very limited set of capabilities:

1. Let me coherently format and style text
2. Let me share documents with other people
3. Let me spell check my work so I don't look like an idot.
4. Let me print my work.

After that anything else that gets added in is a feature I probably won't use. OpenOffice and Google Docs are slowly supplanting Word because they make the user experience better than Word (I'm counting not having to shell out $500 for useless features as part of that user experience) The first version I used of OpenOffice was awesome because it had, right there in the File menu a "Export as PDF". This was a feature - but it made the sharing of documents so much easier that it greatly added to the "sharing" capability - I could email a document and be sure it would look that same way on the person on the other end of tube's computer.

The poster boys for the "less features" community are 37Signals' applications - BaseCamp, HighRise and Backpack in each case they dramatically underfeatured any of the other project management / CRM / intranet suites out there but had all the capabilities that people needed. They also added the capability of "usable by moms and/or CEO's" because their products were so simple and built-on standard web user interface concepts. That's a capability that you don't ever get by adding features - it's something you only get by having solid UX coherency and a lack of confusing and overwhelming features.

If capabilities are so great, then why do we as programmers tend to spend our times focused on features?

Reason one: features are fun. I love coding in new whiz-bang features and I'd bet other developers are the same way. It means I get to walk over to another developer on the project and say "Did you see the sweet new realtime Ajax notification panel I put in?" and they say "Cool" and I feel like I earned my nerd points for the day. Unfortunately if that notification panel doesn't do anything besides add in some eye-candy it's not a win. It's going to be a weight on the codebase that will need to be carried along without adding in real value.

Reason two: far to often project descriptions are in terms of features rather than user stories. Features are easier to describe, more concrete and more estimatable than user stories. This is something that's easily solved though by making sure every feature relates back to a user story. If each feature you're adding in relates back to a user story (e.g. "Sally B. User should be able to login even if she forgot her password" = "Password Reset Feature") then the creepy features won't get in there.

For a great analysis of user stories and how use them to drive your development process I recommend "Head first software Development" from the wildly entertaining O'Reilly "Head First" serious (yes I just called a set of computer books wildly entertaining - once you've read one of the series you'll understand) Despite the title, it's by no means a basic book on programming but actually a great read on the higher level processes involved in making great software.

Remember, focus on capabilities driven by user stories, letting the features generate from the stories and everything will be ok. By the way, did I show you the cool new totally user-driven HTML5 websockets event mash-up stuff I'm working on?