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.
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.
The data (u|dys)topia
Take one simple conversation with a neighbor, add a few late night walks in the dark, and it develops into a complete utopian/dystopian vision of the not-so-distant future.
First, the conversation: we were talking about everyday marital strife, and she mentioned how her husband wants to redo the roof himself — it’s a relatively straightforward project, he’s retired and has the time, and they’d save a lot of money. Her response is that his life cannot possibly be worth the money saved. Result: intractable argument. How can either side prevail? She spoke about couples taking turns “winning” arguments as a way out.
My thought is that it’s actually a question of data. What’s the actual risk that he’d injure or kill himself? If he takes the proper precautions (like a safety line, ladder spotter, etc.), can he make working on the roof safer than driving the car to the store? If yes, her argument goes away. If not — particularly if amateur roof work is dangerous even if the homeowner believes they’re taking precautions — then she wins.