I feel a satire post coming on, but for now I am going to write up a standard speech I have in response to the oft-repeated "Nikon (Olympus, Canon) should do such-and-such because it's just a few lines of code in the firmware". I've built some products over the last 20, um, 22 years and a few months, so I know a little about this sort of thing. If I had 10,000 dollars for every time I've had to shoot down someone who said "Couldntayajust..." I'd be extremely rich.
Hat tip, obviously, to Kirk Tuck. It is not a coincidence that I am writing this post at this time.
Here's how that actually breaks down.
Someone has to define the feature. Like, really define what it does. Let's say you want the ability to assign adjustment of the Frob parameter to a wheel. The Frob parameter exists and is adjustable, but you just can't assign it to a wheel. Simple. A few lines of code.
Which way does the wheel go to make the parameter go up? When you reach the end of the range, what happens, is there an indicator somewhere? How much does one click adjust the parameter? Do we do it on all platforms, or just the ones with at least two wheels? Or three?
You've got to decide these things. So, someone spends a little time thinking it through and writing down some sensible answers, and one or two people who know what's going on review that and make sure it's complete and not insane.
Oh, and now you need the exact text for a menu item. And you'll need a menu item, as well.
Don't forget, someone has to translate the menu item into all the supported languages. And someone has to review the translations to make sure they make sense.
Ok, now we can write some code! For the feature. And the menu item. And don't forget to include it in the "reset to factory defaults" logic, and any custom settings logic, and so on.
Someone has to QA it. But before that, someone has to write it into the test plan. Someone has to translate the detailed definition of the feature into testable attributes, and update the right parts of the most likely several plans with specific tests to make sure that the feature works as defined. On all supported platforms, including those with 1, 2, 3 wheels and the associated possibly different behaviors.
Better update the manual too. And review it. And translate it. And review the translations.
Do we need to test this thing in manufacturing? If so, someone's got to write the section of the manual the manufacturers use, and update the test jigs on the manufacturing floor to allow it to be tested. And review all this. And translate it. And review the translations. And finally build it.
Phew!
Any feature, no matter how small, the smallest most atomic feature imaginable is going to unpack into a week or two of staff time. If you're lucky.
Ok, so you decide to do that. What are we going to drop to make room for this? We can either slip the schedule a little, or we can drop some other work we were going to do.
Your little "few lines of code" feature not only has to generate revenue to cover the week, or two weeks, or year of staff time. It has to generate more revenue than something that's already in the plan. You actually have to be able to move some serious cameras on the basis of this thing.
You would be astonished at the number of times the correct answer is "look, show me a million bucks in revenue and we'll talk, otherwise the numbers simply don't work". I know I'm astonished, and I am sometimes the guy that runs the numbers, at least roughly.
It turns out there's a whole discipline devoted to working out what to include in the plan, when. It's called Product Management, and you can go to school to learn it. And I am fairly confident that Nikon, Canon, Olympus, and all the other camera makers have entire staffs of people who are in fact experts in this discipline, and they're probably making pretty good choices.
It is not in fact true that they don't listen to photographers. They probably read your blog, and they put some of the ideas into the hopper. Not all ideas get implemented, because resources are not infinite. They are, dramatically, finite, and the product management team's actual job is to deploy the finite resources in ways that are most likely to produce the most actual money.
Selling one camera to a pundit is not actual money in any meaningful sense. Even less money is generated when the pundit doesn't even buy the camera because of something else.
I spent many years in the management of medical facilities and human services. Same issues there. Someone (staff, client, patient, etc.) would say "why don't you add this service" or "why don't you offer something at this location." Often the idea was, in fact, good and helpful to the people we served, but bring it on line took far more time and effort than anyone could imagine.
ReplyDeleteIn non-IT organisations (I used to be the systems manager in an academic library), the process you describe often happens internally e.g. someone at senior level demands "why can't WE offer this simple service, which other institutions do?" No amount of explanation (including "they have a different system to us") will allay the suspicion that IT people are intrinsically and instinctively obstructive, and an obstacle to the visionary policies of senior management. Which may, of course, also be true.
ReplyDeleteMike
Yep.
ReplyDeleteLots of people who even write code, or who work with people who write code, don't get it. It's not the code that gets ya, that part is indeed easy. It's the "whole product" envelope that eats you alive, it's the QA, it's the manuals, it's the internationalization, it's the manufacturing, and, ultimately, the fact that there isn't enough time to do it all so you do the things that seem likeliest to generate the most profit.