Reminds me of those vintage mixed-font posters (source).
2011-04-27
The art of choosing fonts
Wells Fargo emails use a pretty wild array of fonts.
Reminds me of those vintage mixed-font posters (source).
Reminds me of those vintage mixed-font posters (source).
This is why Apple wins on mobile devices
I recently switched to an Android phone because my non-evil carrier's data plan is not compatible with the iPhone. I like the MyTouch 4G fine--it's fast, and not hobbled by the same arbitrary restrictions Apple phones are. I like being able to install any email program I want and pick the best. But it's not as polished or slick as the iPhone, in terms of integration and general usability, and if the iPhone were available on non-evil carriers I'd seriously consider switching back.
This gauntlet of installation steps for the Amazon app store application is emblematic of the state of Android on mobile devices:
"That's it"? Seriously?
Most of this is the price of freedom (in the free-software sense) and the all-purpose nature of Android, which is an "open-source software stack for mobile devices" (as opposed to a UI and operating system designed for exactly two devices, the iPhone and iPad): generic software is inevitably less integrated and smooth because it's meant to function in a wide variety of heterogeneous environments (think off-the-rack v. bespoke suits). What's sad is that most attempts at improving the native Android UI and integration seem to be driven more by silly branding and business deals than by a genuine concern for user experience.
Many of the most successful computing products have benefited from a (more-or-less) benevolent dictator making the hard choices about what is or isn't going into the final product: Apple, of course, but also Linux, MySQL and Python come to mind. Compare that to the confusing, inconsistent array of products (even open source) churned out by headless democratic nerd posses like the Mozilla Foundation with its multitude of browsers (Firefox, Camino, SeaMonkey), calendars (Sunbird, Lightning), extensions ("add-ons", "extensions", "plug-ins") and skinning engines (personas v. themes, which are "add-ons" themselves); or the Linux UI community, with Gnome and KDE and so many other options.
Maybe it's time for a strong leader to emerge and make the Android people focus on one optimal, uncluttered, integrated experience. Fat chance.
This gauntlet of installation steps for the Amazon app store application is emblematic of the state of Android on mobile devices:
Download the Amazon Appstore app immediately by clicking [link] from your Android device, or follow the click-by-click guide below.
Click-by-Click Guide
You need to do this only once for each device. The clicks below should take less than 30 seconds.
Click 1
Open your device Settings and click "Applications".
Click 2
If unchecked, click "Unknown sources". If "Unknown sources" is already checked, skip to Click 4.
Note: AT&T Wireless does not support the Amazon Appstore for Android. See Help for more details.
Click 3
Click "OK" on the "Attention" dialog. "Unknown sources" will now have a green check.
Click 4
Open your notifications and click the e-mail message from Amazon Appstore.
Click 5
Click the link: [link]. The Amazon Appstore app will download to your device.
Click 6
Open your notifications and click "Amazon_Appstore.apk".
Click 7
Click "Install".
Click 8
Click "Open".
That's it! Sign in with your Amazon.com account and start enjoying thousands of apps for Android. You need to do this only once for each device.
Most of this is the price of freedom (in the free-software sense) and the all-purpose nature of Android, which is an "open-source software stack for mobile devices" (as opposed to a UI and operating system designed for exactly two devices, the iPhone and iPad): generic software is inevitably less integrated and smooth because it's meant to function in a wide variety of heterogeneous environments (think off-the-rack v. bespoke suits). What's sad is that most attempts at improving the native Android UI and integration seem to be driven more by silly branding and business deals than by a genuine concern for user experience.
Many of the most successful computing products have benefited from a (more-or-less) benevolent dictator making the hard choices about what is or isn't going into the final product: Apple, of course, but also Linux, MySQL and Python come to mind. Compare that to the confusing, inconsistent array of products (even open source) churned out by headless democratic nerd posses like the Mozilla Foundation with its multitude of browsers (Firefox, Camino, SeaMonkey), calendars (Sunbird, Lightning), extensions ("add-ons", "extensions", "plug-ins") and skinning engines (personas v. themes, which are "add-ons" themselves); or the Linux UI community, with Gnome and KDE and so many other options.
Maybe it's time for a strong leader to emerge and make the Android people focus on one optimal, uncluttered, integrated experience. Fat chance.
2011-04-01
2011-03-30
Recursion
CompSci people love recursion. It's elegant and makes for short code that works magically. Of course plain old loops can be faster, less memory-hungry, and easier to grok at 3am after coding for 15 hours, but no matter: recursion rocks.
Still I was surprised to find out that even 419-scammers have become hip to recursion, with this brilliant scam-fighting scam email I got today.
Still I was surprised to find out that even 419-scammers have become hip to recursion, with this brilliant scam-fighting scam email I got today.
What we need now is anti-anti-scam scam emails.Attention Sir/Madam ,
The Federal Government of Nigeria through provisions in Section 419 of the Criminal Code came up with punitive measures to deter and punish offenders.The Advance Fee Fraud section deals mainly with cases of advance fee fraud(commonly called 419) such as obtaining by false pretence through different fraudulent schemes e.g. contract scam, credit card scam, inheritance scam, job scam, loan scam, lottery scam, “wash wash” scam (money washing scam), marriage scam. Immigration scam, counterfeiting and religious scam. It also investigates cyber crime cases.
This is to officially announce to you that some scam Syndicates were apprehended in Lagos, Nigeria few weeks ago and after several interrogations and tortures your details were among those mentioned by some of the scam Syndicates as one of the victims of their operations.
After proper investigations and research at Western Union Money Transfer and Money Gram office to know if you have truly sent money to the scam Syndicates through Western Union Money Transfer or Money Gram, your name was found in Western Union Money Transfer database amongst those that have sent money through Western Union Money Transfer to Nigeria and this proves that you have truly been swindled by those unscrupulous persons by sending money to them in the course of getting one fund or the other that is not real, right now we are working hand in hand with Western Union and Interpol to track every fraudsters down, do not respond to their e-mails, letters and phone calls any longer they are scammers and you should be very careful to avoid being a victim to fraudsters any longer because they have nothing to offer you but to rip-off what you have worked hard to earn.
In this regard a meeting was held between the Board of Directors of The Economic and Financial Crimes Commission (EFCC) and as a consequence of our investigations it was agreed that the sum of Two Hundred And Fifty thousand US Dollars (US$250,000.00) should be transferred to you out of the funds that Federal Government of Nigeria has set aside as a compensation to everyone who have by one way or the other sent money to fraudsters in Nigeria.
***Please note that we will NO LONGER be liable for any loss, cost or expense, whatsoever, suffered or incurred by You in connection with the fraudsters. Be warned!
We have deposited your fund at Western Union Money Transfer agent location EMS Post office Lagos, Nigeria. We have submitted your details to them so that your fund can be transferred to you. We have also paid the Registration and Safe Keeping fees and for security reasons we have also insured your fund to avoid misappropriation.
Contact the Western Union agent office through the email address stated below inform them about this notification letter and the transfer of your fund;
[scam email removed]
Yours sincerely,
Michelle Jones (Miss)
Assistant Investigation Officer.
The Economic and Financial Crimes Commission (EFCC)
15A Awolowo Road, Ikoyi, Lagos.
Nigeria
+234 1 2625189
[scam URL removed]
******************************************************************************************************************
Please note that some fraudsters are claiming to be Directors or staff of The Ecomomic and Financial Crimes Commission have recently been sending phony e-mails/letters and also calling unsuspecting persons, with intent to defraud them. It is important to note that these fraudsters are criminals engaged in Advanced Fee Fraud known in Nigeria as 419. Every day, people throughout the world are falling victim to scams of one kind or another. But remember - if it sounds too good to be true, it is probably a scam. In the circumstance, we unreservedly advice you to dissociate yourself from all correspondence and transactions entered into based on evidently fraudulent and fictitious claims.
******************************************************************************************************************
2011-02-15
Estimating Software Development
Are We There Yet?
As an engineer's career progresses, it's more or less inevitable for her to have to do increasingly complex project management and interact with business folks . Much of the time, what this means is that somebody (usually selling something, either to customers for money or to the board of directors for approval and/or money) needs to know when Flanginator 2.0 will be released. Perhaps just as often, it means that somebody already sold Flanginator 2.0 (in beta, if you're lucky) on a contract starting six weeks from yesterday and they need to know what can be crammed into the next six weeks so they can tell the client what they actually bought. In non-dysfunctional organizations, an engineering manager is eventually called upon to answer a few simple questions:
The Reluctant Leading The Blind
Simplifying grossly, it's helpful to see the typical web shop as a place where software engineers, the Makers' Guild, build things business people sell, and business people, the Merchants' Guild, sell things software engineers build.
Time (to market) and timing are everything to the Merchant, while quality, cleverness and/or craftsmanship are everything to the Maker; and both are completely reasonable. The sooner the Merchant gets to sell a product, and the more closely the product availability can be tied to some important externality (e.g. a trade show, a conference, your customers' budget calendar), the sooner the revenue rolls in, and the harder it is for the competition to catch up. Complementarily, the higher-quality the product, the more satisfied the Maker and her customers are, the more revenue rolls in, and the harder it is for the competition to catch up.
Note each guild's goals are exactly the same as the other guild's--make money and beat the competition. But the two camps are going about it from two very different perspectives: the Merchant is very concerned with time, shrinking it or molding it to fit into a complex web of external calendars and deadlines over which she has very little control. By contrast, time is the least of the Maker's concerns, because she has to worry about building a product that works with no splinters or dead-ends or a shaky foundation--it'll be ready when it's done, and we can't compromise code quality / scalability / employee morale / features / database structures / code reviews / our finely chiseled system architecture just to get the product out faster.
In the best-case scenario, this tension leads to a very brisk product release schedule with constant improvements to products that sell themselves because they're finely tuned to what the market wants. In the worst-case scenario, engineers hate the slimy loose-cannon idiots from sales, and sales people hate the scruffy maladjusted untucked nerds from engineering who couldn't sell a warm jacket to a naked Eskimo.
The Thanksgiving Dinner Parable
Taking my cues from a long-dead craftsman from the Mediterranean region, who used to get a ton of mileage out of ostensibly non-à-propos at all yet profoundly relevant stories about people and things unrelated to the question at hand, I'd like to step back from engineering and sales for a moment to try to get at the crux of the biscuit of software estimates, by considering the commonly-shared experience of the Thanksgiving dinner (at least here in the US; feel free to substitute any other magniprandial calendricality of your choice).
In very simple terms, a Thanksgiving dinner is a family gathering on the last Thursday in November during which a large quantity of home-cooked food is consumed, also at home, by nuclear families and sometimes Others (usually not until they have reached the Significant stage). The meal normally includes a very large turkey, cranberry sauce, mashed potatoes or yams, some non-starchy vegetable, stuffing, gravy, some manner of bread, pumpkin pie, and beverages. It is widely accepted that the average Thanksgiving convive will describe with the most fondness and enjoyment those events having involved the maximum amount of home-cooked items, especially when made entirely from scratch, as against, say, canned cranberry sauce or frozen Sara Lee pumpkin pie, which isn't half bad, if you ask me.
Now, if you ask a Thanksgiving dinner maker how long the whole shebang is going to take, you'll probably get a wide range of answers. A young, first-time cook might say "oh golly, I have no idea, it'll take at least a week, and it's already Tuesday!" as s/he rushes to the grocery store. A Thanksgiving veteran might say "I'd say a morning of shopping, thaw the bird overnight, a day of cooking, so let's call it three days." I'd bet some serious Thanksgiving dinner makers put a lot more time into it, while Thanksgiving dilettantes may devote just a few hours (or none at all and just go to the restaurant or order in). I'd also bet not a single one of those guesses will be near the time it actually takes when all is said and done. People are simply not very good at guesstimating how long things take, unless said things are very few, very well-defined and well-rehearsed, and immune to externalities like a flat tire on the way to the store, a gas leak, frigid temperatures adding five hours to the bird's usual thawing time, etc.
Of course nobody would ask the Thanksgiving dinner maker for a very, very specific estimate of how long it will take, or a very, very detailed breakdown of every little task with a time and a name attached to each. If you requested a Thanksgiving task list from a naive cook you'd probably get something like this:
Many software engineers are Thanksgiving dinner makers, thinking in terms of blocks of functionality that often require a lot of work. And because writing software usually means building something that you haven't built before, there's very little directly applicable hard evidence in your past experience to guide you in your time estimate for the new feature. Some well-rehearsed tasks can be estimated very accurately assuming everything works (e.g. kickstart a new server on standard hardware), but that assumption itself is often faulty since, well, nothing actually works all the time--we're talking about computer hardware and software, and we're barely out of the Ford Model-T era of sophistication and reliability.
So one key to better estimates is to learn and practice the skill of breaking those chunks down into well-defined tasks that can likely accomplished by one or two people in a day or less. If that's too hard, break up your larger features into smaller feature subsets, and break those down into tasks. Use Post-It Notes, with names and time estimates on each of them, line them up on a wall, then add up the times--there's your time estimate. Of course it'll be rough, and three times as long as anyone expected, so that's where you start cutting features and grouping tasks into releasable phases that can be rolled out in daily or weekly increments, or major versions of your software over a longer period of time.
There are diminishing returns the deeper you go into details for your estimate; splitting up a day's work into eight one-hour segments (or smaller) requires a huge amount of upfront analysis and thinking that will most likely be inaccurate or irrelevant by the time you start, since you haven't started writing the software yet and today's guesses about which individual classes and member variables you'll need two weeks from now are mostly a waste of time as the features and implementation details will have changed three times between now and then. So save the very detailed (sub-1-day) breakdowns until you've broken up your feature set into phases, and each phase into bits of functionality, and don't tackle too much in advance--a couple of release cycles at the most, because the work you do today for phase 1 may turn out to invalidate the guesses you make about phase 4.
All that means is that software estimates are just that: estimates. The only time you can precisely say how long a project is going to take is after it's done, and even then it's rarely practical to be exact, because being exact requires either sneaky or overbearingly bureaucratic time-tracking shenanigans, and who has the time?
Note this doesn't absolve the Makers of the responsibility to produce decent estimates, to consciously work at improving them, and to make every reasonable effort to build quality products in accordance with what often seems like a completely fanciful set of arbitrary external deadlines. On the other hand, frank conversations need to take place with the Merchants so that truly arbitrary deadlines that only exist in a Merchant's mind are objectively and clearly separated from the handful of hard deadlines the blowing of which can have truly serious consequences, so that pressure, potential disappointment and ultimate recriminations are kept to a bare minimum.
Real and Fake Deadlines
In addition to estimates, a software engineer's job also requires becoming creative and conversant in the art of compromise. Do you really need the Flanginator to have an electronic stereo klaxon with 127 foot-switchable sounds, or will a hand-activated horn suffice? Does the Flanginator positively, absolutely need to be out and tested by February 12th, or is there flexibility?
Some compromises can't be done: a big turkey will not thaw satisfactorily in two hours. You also can't just eat cranberry sauce and nothing else. Often they can: maybe Whole Foods mashed potatoes are just as good as the ones you were going to make before you fell in the shower and sprained your potato-mashing wrist. Sometimes they're not worth it: do you really want to go to Whole Foods on Thanksgiving Thursday morning, or call in a caterer with 12 hours' notice?
So another key is to be honest with the whole team (Merchants and Makers) and distinguish between real and fake deadlines. Real deadlines are events or signed contracts where having some product is a requirement, like a trade show or a meeting to pitch investors. Blowing those is like having Thanksgiving on Friday--ça ne se fait pas. Sacrifices will likely need to be made all round if the timing gets tight (cut features, hacks, throw-away code). The responsibility is best shared across the team, and your Merchants need to be on board with (and shoulder some of) the sacrifices made to make the deadline. Fake deadlines are those features that just "need to go out tomorrow so this reporter who told me she might write a piece about us for next month's issue can see we're on the ball." Those are more like dinner with friends: no one will die if you skip a weekend, or hang on Saturday rather than Friday, or order in instead of home-baking your famous prime rib cheesecake.
No Eye-Rolling
It's hard to find organizations where engineers don't roll their eyes and complains "Jeez, sales sold something we can't possibly build again. Jill must be trying to max out her quarterly bonus / they have no idea what it takes to build that thing." Those organizations' sales folks are also more likely to wonder "How can we be expected to bring in revenue if engineering won't build products we can sell? Our customers close their budgets by November, so if we don't have Flanginator 2.0 ready to demo by October 17 at 2:17pm EST, then it's an entire year's work down the toilet." This is bad, but not very difficult to address.
Educate your developers and product folks by getting the sales folks' perspective on what the market wants. The sales force is on the ground, talking to customers every day, and has a unique perspective on what kinds of products can be sold, so sales should be involved in the product development. Even a small UI tweak being considered to make something fit more gracefully into a page can have a huge impact on the sellability of a product (maybe it means your paying partner's logo will look smaller, or be their name will be moved off to a less desirable position). The only worse thing than having to scramble to hotfix a roll-back of this change is getting a call from sales right after they hear about the tweak from their very angry paying customers. It's not fair to sales, it's not fair to engineers, and worst of all it's not fair to your paying customers. Get sales involved.
On the engineering side, invite your engineers to industry events, focus groups, and user testing; heck, encourage them to run some of those user-testing sessions. They're inexpensive and eye-opening, and nothing beats hearing the same three wishes or complaints directly from real customers.
Ultimately nothing beats product and business leaders with some technical sense, engineering leaders with some business sense, and engineers who are realistic and honest about what can and can't be done. Ideally the skill sets in a product development organization overlap a bit like this:
If you don't have that today, get started on it now, because your organization is a vital organism that must--and can--change, adapt, learn and improve.
As an engineer's career progresses, it's more or less inevitable for her to have to do increasingly complex project management and interact with business folks . Much of the time, what this means is that somebody (usually selling something, either to customers for money or to the board of directors for approval and/or money) needs to know when Flanginator 2.0 will be released. Perhaps just as often, it means that somebody already sold Flanginator 2.0 (in beta, if you're lucky) on a contract starting six weeks from yesterday and they need to know what can be crammed into the next six weeks so they can tell the client what they actually bought. In non-dysfunctional organizations, an engineering manager is eventually called upon to answer a few simple questions:
- How long will Flanginator 2.0 take to build?
- How much of Flanginator 2.0 can you do to get something out by date X
? - What resources do you need to build Flanginator 2.0 by
event X? - Why is Flanginator 2.0 taking so long?
The Reluctant Leading The Blind
Simplifying grossly, it's helpful to see the typical web shop as a place where software engineers, the Makers' Guild, build things business people sell, and business people, the Merchants' Guild, sell things software engineers build.
Time (to market) and timing are everything to the Merchant, while quality, cleverness and/or craftsmanship are everything to the Maker; and both are completely reasonable. The sooner the Merchant gets to sell a product, and the more closely the product availability can be tied to some important externality (e.g. a trade show, a conference, your customers' budget calendar), the sooner the revenue rolls in, and the harder it is for the competition to catch up. Complementarily, the higher-quality the product, the more satisfied the Maker and her customers are, the more revenue rolls in, and the harder it is for the competition to catch up.
Note each guild's goals are exactly the same as the other guild's--make money and beat the competition. But the two camps are going about it from two very different perspectives: the Merchant is very concerned with time, shrinking it or molding it to fit into a complex web of external calendars and deadlines over which she has very little control. By contrast, time is the least of the Maker's concerns, because she has to worry about building a product that works with no splinters or dead-ends or a shaky foundation--it'll be ready when it's done, and we can't compromise code quality / scalability / employee morale / features / database structures / code reviews / our finely chiseled system architecture just to get the product out faster.
In the best-case scenario, this tension leads to a very brisk product release schedule with constant improvements to products that sell themselves because they're finely tuned to what the market wants. In the worst-case scenario, engineers hate the slimy loose-cannon idiots from sales, and sales people hate the scruffy maladjusted untucked nerds from engineering who couldn't sell a warm jacket to a naked Eskimo.
The Thanksgiving Dinner Parable
Taking my cues from a long-dead craftsman from the Mediterranean region, who used to get a ton of mileage out of ostensibly non-à-propos at all yet profoundly relevant stories about people and things unrelated to the question at hand, I'd like to step back from engineering and sales for a moment to try to get at the crux of the biscuit of software estimates, by considering the commonly-shared experience of the Thanksgiving dinner (at least here in the US; feel free to substitute any other magniprandial calendricality of your choice).
In very simple terms, a Thanksgiving dinner is a family gathering on the last Thursday in November during which a large quantity of home-cooked food is consumed, also at home, by nuclear families and sometimes Others (usually not until they have reached the Significant stage). The meal normally includes a very large turkey, cranberry sauce, mashed potatoes or yams, some non-starchy vegetable, stuffing, gravy, some manner of bread, pumpkin pie, and beverages. It is widely accepted that the average Thanksgiving convive will describe with the most fondness and enjoyment those events having involved the maximum amount of home-cooked items, especially when made entirely from scratch, as against, say, canned cranberry sauce or frozen Sara Lee pumpkin pie, which isn't half bad, if you ask me.
Now, if you ask a Thanksgiving dinner maker how long the whole shebang is going to take, you'll probably get a wide range of answers. A young, first-time cook might say "oh golly, I have no idea, it'll take at least a week, and it's already Tuesday!" as s/he rushes to the grocery store. A Thanksgiving veteran might say "I'd say a morning of shopping, thaw the bird overnight, a day of cooking, so let's call it three days." I'd bet some serious Thanksgiving dinner makers put a lot more time into it, while Thanksgiving dilettantes may devote just a few hours (or none at all and just go to the restaurant or order in). I'd also bet not a single one of those guesses will be near the time it actually takes when all is said and done. People are simply not very good at guesstimating how long things take, unless said things are very few, very well-defined and well-rehearsed, and immune to externalities like a flat tire on the way to the store, a gas leak, frigid temperatures adding five hours to the bird's usual thawing time, etc.
Of course nobody would ask the Thanksgiving dinner maker for a very, very specific estimate of how long it will take, or a very, very detailed breakdown of every little task with a time and a name attached to each. If you requested a Thanksgiving task list from a naive cook you'd probably get something like this:
- go shopping (2 hours)
- thaw the frozen turkey (36 hours)
- cook turkey (6 hours)
- make pumpkin pie (2 hours)
- etc.
- drive to Trader Joe's (10 minutes)
- find a place to park and walk to store (10 minutes)
- shop (25 minutes)
- stand in at the register in the crowded store (10 minutes)
- go back to car, load trunk, return cart (5 minutes)
- drive to Safeway for the rest of the stuff (10 minutes)
- find a place to park and walk to store (10 minutes)
- shop (25 minutes)
- stand in at the register in the crowded store (10 minutes)
- go back to car, load trunk, return cart (5 minutes)
- go to the farmer's market because the asparagus was just ugly (10 minutes)
- shop at farmer's market (1 hour)
- get gas (10 minutes)
- go home (10 minutes)
- unload (10 minutes)
Many software engineers are Thanksgiving dinner makers, thinking in terms of blocks of functionality that often require a lot of work. And because writing software usually means building something that you haven't built before, there's very little directly applicable hard evidence in your past experience to guide you in your time estimate for the new feature. Some well-rehearsed tasks can be estimated very accurately assuming everything works (e.g. kickstart a new server on standard hardware), but that assumption itself is often faulty since, well, nothing actually works all the time--we're talking about computer hardware and software, and we're barely out of the Ford Model-T era of sophistication and reliability.
So one key to better estimates is to learn and practice the skill of breaking those chunks down into well-defined tasks that can likely accomplished by one or two people in a day or less. If that's too hard, break up your larger features into smaller feature subsets, and break those down into tasks. Use Post-It Notes, with names and time estimates on each of them, line them up on a wall, then add up the times--there's your time estimate. Of course it'll be rough, and three times as long as anyone expected, so that's where you start cutting features and grouping tasks into releasable phases that can be rolled out in daily or weekly increments, or major versions of your software over a longer period of time.
There are diminishing returns the deeper you go into details for your estimate; splitting up a day's work into eight one-hour segments (or smaller) requires a huge amount of upfront analysis and thinking that will most likely be inaccurate or irrelevant by the time you start, since you haven't started writing the software yet and today's guesses about which individual classes and member variables you'll need two weeks from now are mostly a waste of time as the features and implementation details will have changed three times between now and then. So save the very detailed (sub-1-day) breakdowns until you've broken up your feature set into phases, and each phase into bits of functionality, and don't tackle too much in advance--a couple of release cycles at the most, because the work you do today for phase 1 may turn out to invalidate the guesses you make about phase 4.
All that means is that software estimates are just that: estimates. The only time you can precisely say how long a project is going to take is after it's done, and even then it's rarely practical to be exact, because being exact requires either sneaky or overbearingly bureaucratic time-tracking shenanigans, and who has the time?
Note this doesn't absolve the Makers of the responsibility to produce decent estimates, to consciously work at improving them, and to make every reasonable effort to build quality products in accordance with what often seems like a completely fanciful set of arbitrary external deadlines. On the other hand, frank conversations need to take place with the Merchants so that truly arbitrary deadlines that only exist in a Merchant's mind are objectively and clearly separated from the handful of hard deadlines the blowing of which can have truly serious consequences, so that pressure, potential disappointment and ultimate recriminations are kept to a bare minimum.
Real and Fake Deadlines
In addition to estimates, a software engineer's job also requires becoming creative and conversant in the art of compromise. Do you really need the Flanginator to have an electronic stereo klaxon with 127 foot-switchable sounds, or will a hand-activated horn suffice? Does the Flanginator positively, absolutely need to be out and tested by February 12th, or is there flexibility?
Some compromises can't be done: a big turkey will not thaw satisfactorily in two hours. You also can't just eat cranberry sauce and nothing else. Often they can: maybe Whole Foods mashed potatoes are just as good as the ones you were going to make before you fell in the shower and sprained your potato-mashing wrist. Sometimes they're not worth it: do you really want to go to Whole Foods on Thanksgiving Thursday morning, or call in a caterer with 12 hours' notice?
So another key is to be honest with the whole team (Merchants and Makers) and distinguish between real and fake deadlines. Real deadlines are events or signed contracts where having some product is a requirement, like a trade show or a meeting to pitch investors. Blowing those is like having Thanksgiving on Friday--ça ne se fait pas. Sacrifices will likely need to be made all round if the timing gets tight (cut features, hacks, throw-away code). The responsibility is best shared across the team, and your Merchants need to be on board with (and shoulder some of) the sacrifices made to make the deadline. Fake deadlines are those features that just "need to go out tomorrow so this reporter who told me she might write a piece about us for next month's issue can see we're on the ball." Those are more like dinner with friends: no one will die if you skip a weekend, or hang on Saturday rather than Friday, or order in instead of home-baking your famous prime rib cheesecake.
No Eye-Rolling
It's hard to find organizations where engineers don't roll their eyes and complains "Jeez, sales sold something we can't possibly build again. Jill must be trying to max out her quarterly bonus / they have no idea what it takes to build that thing." Those organizations' sales folks are also more likely to wonder "How can we be expected to bring in revenue if engineering won't build products we can sell? Our customers close their budgets by November, so if we don't have Flanginator 2.0 ready to demo by October 17 at 2:17pm EST, then it's an entire year's work down the toilet." This is bad, but not very difficult to address.
Educate your developers and product folks by getting the sales folks' perspective on what the market wants. The sales force is on the ground, talking to customers every day, and has a unique perspective on what kinds of products can be sold, so sales should be involved in the product development. Even a small UI tweak being considered to make something fit more gracefully into a page can have a huge impact on the sellability of a product (maybe it means your paying partner's logo will look smaller, or be their name will be moved off to a less desirable position). The only worse thing than having to scramble to hotfix a roll-back of this change is getting a call from sales right after they hear about the tweak from their very angry paying customers. It's not fair to sales, it's not fair to engineers, and worst of all it's not fair to your paying customers. Get sales involved.
On the engineering side, invite your engineers to industry events, focus groups, and user testing; heck, encourage them to run some of those user-testing sessions. They're inexpensive and eye-opening, and nothing beats hearing the same three wishes or complaints directly from real customers.
Ultimately nothing beats product and business leaders with some technical sense, engineering leaders with some business sense, and engineers who are realistic and honest about what can and can't be done. Ideally the skill sets in a product development organization overlap a bit like this:
If you don't have that today, get started on it now, because your organization is a vital organism that must--and can--change, adapt, learn and improve.
2010-11-22
Lolspeak in The Gap and Lowly Passengers
Mozilla: Please Fix This
All the tools I use professionally are open source, with the exception of MS Office and Visio. My browser is Firefox, my email client is Thunderbird, and I manage my calendars with whichever calendaring program wasn't abandoned by Mozilla. By and large Mozilla software it's pretty good. It does the job very well much of the time, and competently almost all the time; but I do wish Mozilla had a little more UI sense and discipline to make better, clearer choices in their product development.
Tabs, Tabs, Everywhere
Thunderbird makes a big deal of its tabs. "Now with tabs, better search, and email archiving" is the main selling point on the download page:
Now, I'm all for innovative UIs, but did the world really need tabs for email? Email has been around for decades, and mostly mainstream for 15 years. Most consumer desktop programs open a new window when you open an email. It's pretty much the standard paradigm for desktop clients; web and mobile clients are probably making this paradigm semi-obsolete, but millions of people use desktop email programs every day, so it's not dead yet. And I don't think tabs are the way to go for email.
Sure, you could make the same argument about browsers: before tabbed browsers started gaining market share, new pages opened in new windows, but tabs have proven themselves as a superior alternative for many people. No argument from me; I used a tabbed wrapper around IE back when Firefox (then Firebird) was more unstable than Jeffrey Dahmer. But a browser has one primary function (viewing web pages), whereas email clients have a long history of letting you manage more than just email, with calendaring, to-dos, notes, and various other things. And that is where the tabbed design breaks down, and why emails shouldn't be opening in tabs. Note I don't expect the Mozilla people to read, care about, agree with, or implement any of these suggestions; after all, it took them years to fix the horrible usability error whereby you couldn't disable the functionality that marks emails as read when displayed in the preview pane. This is the one problem that prevented me from using Thunderbird as my email client. It's now an option, and disabled by default, if memory serves--thanks! But I'm going to gripe^H^H^H^H^Hwrite about it anyway.
It's a pretty common occurrence for me to get an email trying to set up a meeting, with "Does Thursday at 3 work for you?" That's not exactly convenient if you use Thunderbird for calendaring with the Lightning plug-in--now you have an email in a tab, and your calendar in a tab, and so you can't look at them at the same time. You can't alt-tab between them. You have to be keyboard-savvy enough to know that ctrl-tab is how you flip through tabs in a tabbed MDI program. Opening an email in a tab is also not as dramatic visually as opening a new window, so it was pretty frequent for me to open an email multiple times because I hadn't seen the new tab.
Tabs work well for distinct top-level features in Thunderbird: email, calendar, notes, to-dos, etc. Using tabs for sub-features of any of these breaks the hierarchy.
To their credit, Thunderbird lets you disable tabs for email, and that's the first thing I did, but it shouldn't be the default.
Drag Queens
While on the subject of Thunderbird, when dragging attachments onto a message window, why does the main message body not register the drop, while the "To:" section does? What kind of sense does that make?
Conceptually, the attachment is closer to the body of the message; it has nothing to do with the recipients. I understand why the whole address section is a drop target--that's because the attachment summary opens a little square to the right of the address section when you've added an attachment. But that square is nowhere to be seen until you've added said attachment, making it very non-obvious how you're supposed to attach files, especially if you've tried to drop a file onto the message body and failed. Come on, folks, this isn't hard. Get it right.
Tangent #1
Speaking of drag and drop: why do bloggers and web content creators still put up with the pre-2000 model of having to explicitly upload their photos via a dedicated upload form, and (if they're lucky) move it into place in their rich-text editor? Why haven't enough smart techies come up with a standard way to let people just drag a photo from their desktop onto their rich-text editor and have it show up in the right place, without having their text reflowed or mangled beyond repair?
I know the technical answer; what I want to know is why people aren't angry enough about it to demand a fix. Software should be transparent; exposing the nasty technical guts of the software by not providing an integrated experience is a sad cop-out, and the web community should do better.
More T-Bird
While on the topic of Thunderbird, another little thing that wouldn't hurt is to add a little intelligence into the parsing and display of the email. Apple's terrible Mail program does this remarkably well by automatically highlighting words like "yesterday" and "tomorrow" and showing a context menu to create events in their otherwise execrable iCal program; it also highlights contact information like phone numbers detected inside an email.
What I'd like Thunderbird to do is be a little smarter in the message display. When someone receives a message and highlights a section of it, then right-clicks on it, why not show a Search for xxx in your browser (using the default browser and search settings)? Even better: if you can detect that the highlighted string is an address, add a link to a map (a Google map would guarantee even more money for the Mozilla foundation); a phone number? Show a context menu to add it to your address book (together with sender's name and email), or overlay the contact's info if you can find it in the address book.
Yes, I know, I can edit the code myself and probably finagle my changes into the trunk, but why should I have to?
Pick One
One last gripe: I wish the Mozilla folks would just focus a little. Why have plug-ins, add-ons and extensions? Why even use that awful phrase "add-on", when "extension" is pretty clear (extensions extend the basic functionality, get it?) and a lot less techy? Similarly, why have both themes and personas? And why have Firefox, Seamonkey and Camino? Why not call them Firefox, Firefox Suite and Firefox for Mac, if you must distinguish, since they share so much of their rendering technology? What are the differences within those product families? Is there a difference? Most importantly, why should the end-user care?
With double-digit market share, Firefox isn't the bailiwick of basement-dwelling, Gentoo-compiling geeks anymore, so the old hyper-specific tech terminology needs a revamp.
Tabs, Tabs, Everywhere
Thunderbird makes a big deal of its tabs. "Now with tabs, better search, and email archiving" is the main selling point on the download page:
Now, I'm all for innovative UIs, but did the world really need tabs for email? Email has been around for decades, and mostly mainstream for 15 years. Most consumer desktop programs open a new window when you open an email. It's pretty much the standard paradigm for desktop clients; web and mobile clients are probably making this paradigm semi-obsolete, but millions of people use desktop email programs every day, so it's not dead yet. And I don't think tabs are the way to go for email.
Sure, you could make the same argument about browsers: before tabbed browsers started gaining market share, new pages opened in new windows, but tabs have proven themselves as a superior alternative for many people. No argument from me; I used a tabbed wrapper around IE back when Firefox (then Firebird) was more unstable than Jeffrey Dahmer. But a browser has one primary function (viewing web pages), whereas email clients have a long history of letting you manage more than just email, with calendaring, to-dos, notes, and various other things. And that is where the tabbed design breaks down, and why emails shouldn't be opening in tabs. Note I don't expect the Mozilla people to read, care about, agree with, or implement any of these suggestions; after all, it took them years to fix the horrible usability error whereby you couldn't disable the functionality that marks emails as read when displayed in the preview pane. This is the one problem that prevented me from using Thunderbird as my email client. It's now an option, and disabled by default, if memory serves--thanks! But I'm going to gripe^H^H^H^H^Hwrite about it anyway.
It's a pretty common occurrence for me to get an email trying to set up a meeting, with "Does Thursday at 3 work for you?" That's not exactly convenient if you use Thunderbird for calendaring with the Lightning plug-in--now you have an email in a tab, and your calendar in a tab, and so you can't look at them at the same time. You can't alt-tab between them. You have to be keyboard-savvy enough to know that ctrl-tab is how you flip through tabs in a tabbed MDI program. Opening an email in a tab is also not as dramatic visually as opening a new window, so it was pretty frequent for me to open an email multiple times because I hadn't seen the new tab.
Tabs work well for distinct top-level features in Thunderbird: email, calendar, notes, to-dos, etc. Using tabs for sub-features of any of these breaks the hierarchy.
To their credit, Thunderbird lets you disable tabs for email, and that's the first thing I did, but it shouldn't be the default.
Drag Queens
While on the subject of Thunderbird, when dragging attachments onto a message window, why does the main message body not register the drop, while the "To:" section does? What kind of sense does that make?
Conceptually, the attachment is closer to the body of the message; it has nothing to do with the recipients. I understand why the whole address section is a drop target--that's because the attachment summary opens a little square to the right of the address section when you've added an attachment. But that square is nowhere to be seen until you've added said attachment, making it very non-obvious how you're supposed to attach files, especially if you've tried to drop a file onto the message body and failed. Come on, folks, this isn't hard. Get it right.
Tangent #1
Speaking of drag and drop: why do bloggers and web content creators still put up with the pre-2000 model of having to explicitly upload their photos via a dedicated upload form, and (if they're lucky) move it into place in their rich-text editor? Why haven't enough smart techies come up with a standard way to let people just drag a photo from their desktop onto their rich-text editor and have it show up in the right place, without having their text reflowed or mangled beyond repair?
I know the technical answer; what I want to know is why people aren't angry enough about it to demand a fix. Software should be transparent; exposing the nasty technical guts of the software by not providing an integrated experience is a sad cop-out, and the web community should do better.
More T-Bird
While on the topic of Thunderbird, another little thing that wouldn't hurt is to add a little intelligence into the parsing and display of the email. Apple's terrible Mail program does this remarkably well by automatically highlighting words like "yesterday" and "tomorrow" and showing a context menu to create events in their otherwise execrable iCal program; it also highlights contact information like phone numbers detected inside an email.
What I'd like Thunderbird to do is be a little smarter in the message display. When someone receives a message and highlights a section of it, then right-clicks on it, why not show a Search for xxx in your browser (using the default browser and search settings)? Even better: if you can detect that the highlighted string is an address, add a link to a map (a Google map would guarantee even more money for the Mozilla foundation); a phone number? Show a context menu to add it to your address book (together with sender's name and email), or overlay the contact's info if you can find it in the address book.
Yes, I know, I can edit the code myself and probably finagle my changes into the trunk, but why should I have to?
Pick One
One last gripe: I wish the Mozilla folks would just focus a little. Why have plug-ins, add-ons and extensions? Why even use that awful phrase "add-on", when "extension" is pretty clear (extensions extend the basic functionality, get it?) and a lot less techy? Similarly, why have both themes and personas? And why have Firefox, Seamonkey and Camino? Why not call them Firefox, Firefox Suite and Firefox for Mac, if you must distinguish, since they share so much of their rendering technology? What are the differences within those product families? Is there a difference? Most importantly, why should the end-user care?
With double-digit market share, Firefox isn't the bailiwick of basement-dwelling, Gentoo-compiling geeks anymore, so the old hyper-specific tech terminology needs a revamp.
2010-11-18
Twitter: Unsafe at Any Speed
I'm a very light Twitter user. The value of the service is still mostly alien to me. And on the rare occasions I log on (or try to) and post something (or try to), something doesn't work.
I've actually been keeping track and found that Twitter breaks on elementary, "mission-critical", sine-qua-non functionality (like logging on, posting a tweet, or refreshing your stream; not the fancy stuff like uploading a photo or anything--I'm talking about operations without which there is no Twitter service) a full 66% of the time (that's two out of every three times I log on to Twitter).
I know scale is hard, but with over $150M in the bank and tech people begging to work for them, you'd think they'd have the absolute basicswhaled nailed and rock-solid by now. As it is, they have more in common with my old 1983 Plymouth Horizon and its lovely (un)planned obsolescence, except people are treating it like it's a gold-plated Veyron.
Even their log-out functionality is broken right now:
I'll readily forgive a brand-new startup site in beta built by 2 unpaid engineers functioning on espresso and Red Bull throwing out erroneous 403s occasionally. But a supposedly major consumer site with $160M in funding, ~330 employees (as of 11/18/10), and dozens of engineers and operations people, trying to paint itself as a major force for marketing on the internet, at 11pm PST on a Thursday night? I don't believe for one second a technical staff that big, hip and passionate about their product is stupid, careless or incompetent--I'm just baffled. And yes, Twitter is big and has novel scale problems, but they're not the largest site on the web, and I don't remember a single time when google.com failed to perform a search or display their home page. Do you?
I know the world has gone completely insane about Twitter (another round of funding at a multi-billion-dollar valuation is supposedly in the works), but these guys seriously need to stop screwing around and solve their two biggest problems (stability and monetization) once and for all. Until then, I'll keep fail-whale-watching with the other haterz.
I've actually been keeping track and found that Twitter breaks on elementary, "mission-critical", sine-qua-non functionality (like logging on, posting a tweet, or refreshing your stream; not the fancy stuff like uploading a photo or anything--I'm talking about operations without which there is no Twitter service) a full 66% of the time (that's two out of every three times I log on to Twitter).
I know scale is hard, but with over $150M in the bank and tech people begging to work for them, you'd think they'd have the absolute basics
Even their log-out functionality is broken right now:
I'll readily forgive a brand-new startup site in beta built by 2 unpaid engineers functioning on espresso and Red Bull throwing out erroneous 403s occasionally. But a supposedly major consumer site with $160M in funding, ~330 employees (as of 11/18/10), and dozens of engineers and operations people, trying to paint itself as a major force for marketing on the internet, at 11pm PST on a Thursday night? I don't believe for one second a technical staff that big, hip and passionate about their product is stupid, careless or incompetent--I'm just baffled. And yes, Twitter is big and has novel scale problems, but they're not the largest site on the web, and I don't remember a single time when google.com failed to perform a search or display their home page. Do you?
I know the world has gone completely insane about Twitter (another round of funding at a multi-billion-dollar valuation is supposedly in the works), but these guys seriously need to stop screwing around and solve their two biggest problems (stability and monetization) once and for all. Until then, I'll keep fail-whale-watching with the other haterz.
Encouraging Piracy, Part XLII
Queuing up a video on Hulu, I ran into this absurd notice:
Why should I be able to watch this video on my computer but not on my iPhone, or Hulu-enabled TV/Blu-Ray player, when I can watch other videos on any device? Why can I stream some shows on Netflix, while others require a physical DVD to be shipped to me? What kind of sense does any of this make to anybody? Restricting access in any way (not just to some arbitrary collection of devices) means smaller residual checks for actors, fewer royalties to the studios, fewer opportunities to display ads, and pissed off users who just want to watch a show. Everybody loses. The display device should be completely irrelevant. This is just as absurd as a book you can read in bed or on your sofa, but not on a beach chair or a commuter train. Or a CD that can only be played on players approved by the manufacturer. Nobody would do that sort of thing. Right?
In the meantime, people who download torrents get their content quickly and can watch it whenever, wherever they want, on any device they own, unencumbered by meaningless, arbitrary restrictions.
Other than the Soup Nazi, I can't think of any business that is so obdurately hostile to the people that support it financially. Doesn't anybody in the entertainment industry realize they'll keep shrinking and alienate everyone around them for as long as they make piracy the most attractive method for accessing their content?
Why should I be able to watch this video on my computer but not on my iPhone, or Hulu-enabled TV/Blu-Ray player, when I can watch other videos on any device? Why can I stream some shows on Netflix, while others require a physical DVD to be shipped to me? What kind of sense does any of this make to anybody? Restricting access in any way (not just to some arbitrary collection of devices) means smaller residual checks for actors, fewer royalties to the studios, fewer opportunities to display ads, and pissed off users who just want to watch a show. Everybody loses. The display device should be completely irrelevant. This is just as absurd as a book you can read in bed or on your sofa, but not on a beach chair or a commuter train. Or a CD that can only be played on players approved by the manufacturer. Nobody would do that sort of thing. Right?
In the meantime, people who download torrents get their content quickly and can watch it whenever, wherever they want, on any device they own, unencumbered by meaningless, arbitrary restrictions.
Other than the Soup Nazi, I can't think of any business that is so obdurately hostile to the people that support it financially. Doesn't anybody in the entertainment industry realize they'll keep shrinking and alienate everyone around them for as long as they make piracy the most attractive method for accessing their content?
2010-11-10
Lying with charts
Charts can be very useful for capturing complex data and making it understandable. They're also very easy to use maliciously (or stupidly) to mislead and dramatically exaggerate differences. This chart (source) is such an example.
The leftmost green bar is 362 pixels tall, with a fairly tall point at the top. The rightmost blue bar is 52 pixels tall, with a somewhat flat point. This suggests the site with the green bar (a nice, warm, winning, "green means go" color) has almost 7 times as much traffic as the site with the blue bar (a cold color).
But if you look at the actual numbers at the top of each bar, you'll see that the short bar (6.149M) is only 2.3 times shorter than the tall bar (14.340M). That's because the y axis conveniently doesn't start at zero. The net effect is a 3x magnification of the actual difference. Yet the chart maker can still safely claim they're not lying, and indeed they're not--the numbers are right there, undoctored, for all to see. But the damage from the giant visual difference is already done.
Shrinking the scale of a chart like this so it doesn't start at zero is dishonest. Chart junk like fake-3D bars with taller pointy tops on taller bars only makes it worse. Zillow, you should be ashamed of yourself. Maybe your chief economist could come forward and disavow this piece of agitprop for what it is.
Disclosure: I led Trulia's Data Services team until August, 2010. I no longer work there, but still work on producing accurate data that informs and doesn't lie.
The leftmost green bar is 362 pixels tall, with a fairly tall point at the top. The rightmost blue bar is 52 pixels tall, with a somewhat flat point. This suggests the site with the green bar (a nice, warm, winning, "green means go" color) has almost 7 times as much traffic as the site with the blue bar (a cold color).But if you look at the actual numbers at the top of each bar, you'll see that the short bar (6.149M) is only 2.3 times shorter than the tall bar (14.340M). That's because the y axis conveniently doesn't start at zero. The net effect is a 3x magnification of the actual difference. Yet the chart maker can still safely claim they're not lying, and indeed they're not--the numbers are right there, undoctored, for all to see. But the damage from the giant visual difference is already done.
Shrinking the scale of a chart like this so it doesn't start at zero is dishonest. Chart junk like fake-3D bars with taller pointy tops on taller bars only makes it worse. Zillow, you should be ashamed of yourself. Maybe your chief economist could come forward and disavow this piece of agitprop for what it is.
Disclosure: I led Trulia's Data Services team until August, 2010. I no longer work there, but still work on producing accurate data that informs and doesn't lie.
Subscribe to:
Posts (Atom)