Posts in Category: Technical

Why Don’t Developers Like to Estimate Time Accurately?

I was reading this just now – Why Can’t Developers Estimate Time? – and realized the discussion leaves out some fairly important psychological factors that influence time estimates significantly.

As the developer, you focus on the risky bits — the parts that are technically difficult & complex, that use new APIs or new libraries you aren’t familiar with, that require designing a new UI, or matching very strict performance tolerances.

For these sections, developers (with a little training) can learn how to estimate as well as possible — it’s hard, we know it’s hard, and either we’ll say “that’ll take a long time” or we say “we’d better do a proof-of-concept first, because I’m not sure at all how that will go.”

Now we get to the rest of it — the trivial parts. Writing some simple tests, taking input, validating it, storing it, returning something else simple straight out of the database… it’s simple, it’s boring, and any developer on the team could do it.

But it always takes an embarrassingly long time (with the emphasis on “embarrassing”).

Creative procrastination

I was taking Mrs. Bang for a walk last night, at 2am or so, and mulling over my ideas for a dauntingly large new feature I want to add to my music theory site. One idea spun from another, and I started thinking about mad libs — you know, the game where you fill in the blanks in a pre-written story with input from your friends (“adjective about a person”, “action ending with -ing”, “unusual animal”), then read the resulting silliness aloud.

Well, an online mad-lib engine would be pretty trivial to write — just collect the words from the user first, and plug them into the text of the story in the right places. You could play madlibs at a party without anyone knowing beforehand what the final result would be, or even play alone.

I jumped from there to erotic madlibs, which seemed at the time to be an amazingly good idea (it would have to be real erotica at heart, but somehow incredibly enriched by the carefully-placed randomness of the contributed words; sometimes silly, but still sexy). I could register “FillInMyBlank.com” or something else slyly racy (or just MadLibErotica.com?) and put up a few good stories for free access, plus a library for subscribers only, and wait, wait, subscribers could also contribute their own stories — there would have to be rules on content, because I don’t want the site to fill up with sexist shite, of course — and….

By this time I was back home. Wow, the domain names I had thought up were ALL available! No one was doing this already! I was already thinking about how to structure the site (should I build on one of the PHP CMSes? Or play with GWT, maybe?). For a user entering a new story, after each paragraph was entered I could pull the text from the textarea in JavaScript, format it to make each word a separate link… hover to highlight, click to show an overlay for replacing it with a “blank” plus description.

I dug around in my pocket for my credit card to register the domain.

The “now you are spending money” alarm went off in my head, so I paused for a second, then a few more seconds.

This all took place in maybe 20 minutes. And here I was, about to launch into an entirely new project at two something AM, Thursday night, because —

Because it was such an amazing idea, right? Hah, no.  It was losing the halo fast now (er, who exactly would subscribe to this site, now?).

No, this was just my brain saying “huh, this looks like a lot of work you have to do here, some complicated stuff that’ll probably take a lot of — holy crap, look over there!”

Nice.  I put the credit card away.

And tonight, I’m writing it up at 3am to share this valuable and entertaining… ah.

An Approach to Exception Handling

[In response to this post, also posted here, asking about guidelines different developers have come up with….  I actually started a response on the site, then realized I was typing an entire essay into a little comment box.]

Guideline #1: Never discard exception information.

You might either wrap the exception and throw the wrapper, or log it somehow — but discarding exception information should always set off loud alarm bells.  Likewise, catching an exception and throwing a new exception is bad if you neglect to wrap the original one — that stack trace is valuable!

Support Firefox, through Internet Explorer

If you’re a web developer (or if you have to use websites that are still IE-only) you might spend time browsing in both Firefox and IE.

You may also have noticed that when you use the toolbar search box in either one, the browser tacks a few extra parameters onto the Google search URL… so they get credit from Google for sending a user their way.  More specifically, they get PAID.  Which is a great way for Mozilla to support continued open source development… but maybe you don’t want your searches in Internet Explorer to be funneling Google’s money off to Microsoft instead, just because you have to use IE now & then.

Well, if you’ve got a mild anti-Microsoft streak and would like to do a little bit extra to fund open source, it’s pretty easy to tweak IE so that it will build your Google searches to credit Firefox, instead of IE.

Avoiding getting flashed by Dilbert

I’ve been reading the Dilbert comics online for years, always from the archive page — the home page was just overwhelmingly cluttered by ads, and it required extra clicks to see previous comics when I’d missed a few days.

So when the central Dilbert site switched to a super Flash-heavy format for their homepage (including the strip itself!) and the complaints erupted, I snickered smugly.  The archive page hadn’t changed.  I wasn’t affected.

Well, it took about 2 days.  Now the central archive page redirects to dilbert.com.

Disconnected ShareThis plugin for WordPress

I see the ShareThis plugin on tons of WordPress blogs — and with reason, because the presentation is quite nice. You don’t have to take up a chunk of the screen listing all of the different social networks (and they keep multiplying…) or offering the option to email this post to a friend; instead you have a simple link that shows all of the useful detail in a little popup.

ShareThis was so popular, in fact, that a business has sprouted up around it — and current versions of the plugin are tightly bound into the ShareThis.com website. They collect data every time anyone even clicks the link to open the ShareThis window, the social networks links all redirect through the ShareThis.com servers, and all that data (associated with your website) is there for detailed reporting if you register with them. They now also encourage your visitors to sign up. I’m sure it has its uses, and they’re supported by advertising revenue, so they want lots of people to sign up and I imagine they use all that data in conjunction with showing those ads.

404 pages on 1&1 webhosting: complaint and solution

I had an unpleasant surprise today when I was testing a new site I’m setting up using 1&1 web hosting… I mistyped the URL, and lo and behold, instead of showing any kind of useful error page for the 404, the server neatly redirected my browser to a completely different URL, “domparking.php” at the “sedoparking.com” domain. [I’m carefully not linking, and don’t visit the page; I’m sure they get advertising revenue from it.]

I’ve seen default 404 pages where the host sneaks in a few of their own ads, and that’s kind of annoying. But there’s still a message in there somewhere that tells the person they hit a bad link.

This, though — it looks like the domain is parked. Like the site doesn’t exist at all. That’s not good.

Close
Powered by ShareThis (custom mod)