| Date: | August 22, 2005 / year-entry #235 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050822-11/?p=34483 |
| Comments: | 68 |
| Summary: | The Tablet PC team have a tough task ahead of them at this year's PDC: They have to get people to care about power management. The reason why this is tough is that power management is rarely a deal-maker. If a user is evaluating, say, personal finance software, how much weight are they going to place... |
The Tablet PC team have a tough task ahead of them at this year's PDC: They have to get people to care about power management. The reason why this is tough is that power management is rarely a deal-maker. If a user is evaluating, say, personal finance software, how much weight are they going to place on which program consumes less battery power? That's probably a third- or fourth-level tiebreaker. No amount of power management is going to overcome the fact that your program's interface is harder to use than your competitor's. Nobody ever said, "Oh, yeah, I switched my word processor from X to Y because X was chewing too much battery power." When a battery doesn't last very long, users tend to blame the battery, not the software that is draining it. Power management falls into a category some development teams call "taxes". It's something you do, not because it actually benefits you specifically, but because it benefits the software landscape as a whole. Other taxes include making sure your program plays friendly with roaming user profiles, Fast User Switching, Hierarchical Storage Management, multiple monitors, Remote Desktop, and 64-bit Windows. Of course, not all development teams in the world are so diligent as to pay all their "taxes". I suspect most cheat on their taxes, and some of them just don't pay any at all. So here's my question to you: How do you convince developers to pay their "taxes"? (Should developers have to pay taxes at all?) |
Comments (68)
Comments are closed. |
Speaking for myself, I’m happy to do things "The Right Way (TM)", but I often don’t know what that is (which is one reason I read this blog). E.g. I’ve been writing VB apps for the last 11 years, and I have no idea how to affect their power consumption. I wasn’t even aware that it was an issue (I thought it would only affect people who write drivers).
Realistically, I’m not going to go jetting across the Atlantic to attend a conference on this type of thing, but I am willing to invest time/money in reading. So, I guess the most important step is to actually make the information readily available.
LET THEM KNOW. I don’t know how to do any of the above, except for making my code 64-bit-clean by not doing any wacky flag bit stuff.
I remember your article on user profiles, but I haven’t got the slightest clue about HSM or multiple monitors.
I’ll bet most people don’t have a clue a lot of this is even necessary, much less how to do it.
Plus I’m sure in the usual corporate environment, this would be the first thing to be dropped to meet a ship date. For example, how many neat features had to be axed from Longhorn? You KNOW the PHBs are going to say "nobody has multiple monitors" even when customers complain.
(Speaking of features, it would be nice for the comment-add UI to have a "preview" function, and at least a 50% wider "comments" window – just a grumble)
2. Make doing the boring "tax" parts as easy as possible: provide good documentation, New Project wizards that include this stuff, and good quality samples that allow developers to cut and paste.
That’s a good question but at least they are letting their developers who want to pay taxes go ahead and pay them.
One of the most frustrating things when working on small devices is when they don’t give you access to power managment. A classic example being J2ME. It would be really nice if a J2ME app could know if they phone or sensor is about to die but it doesn’t unless the device manufactorer gives you a special non-J2ME standard API to use like RIM for their Blackberrys.
Having worked with this frustration many times I would say in answer to your "Should developers have to pay taxes at all?" question, yes they should, especially on small devices or when doing embedded work. To not have access to be able to pay those taxes can be beyond frustrating in small device work.
Those are my two cents.
Successful businesses in any field don’t pay voluntary taxes. Change requires consumer demand or legislation (although nobody’s going to legislate for these kinds of things, obviously.) The history of car manufacture provides a good example: it wasn’t until the market matured that features such as safety and fuel economy became important.
Perhaps when all software is "good enough" consumers will start to worry about the "taxes" and developers will be forced to satisfy the demand.
Make it a user-visible feature. If the system contains a highly visibly "Power Consumption Monitor" that lists the power-wasting applications, users will start to demand power efficiency (and developers will be able to see that their program wastes power).
It might be enough to add an "(estimated) power consumption" row to the task manager’s process view, and show this row by default on devices that run on batteries.
Most of us aren’t aware that they exist…some simple steps to help this:
1) Build them into the IDE as ‘Have you done this?’ tasks when someone starts a new project. Quick and simple.
1a) Build boiler place code into the default templates as well…
2) Build some rules into a code checker? I can’t remember the one MS wrote for .Net just now…
3) Document it in one place and keep it up to date as a list of ‘taxes you need to pay’. The big problem with MSDN is that the number of articles keeps multiplying – all with related information. You think you’ve found the right one only to discover another one later on…
Best regards
Steve
I too am curious how the coding habits of today affect modern desktop & laptop behavior. Here is one example of how it used to affect laptops: Way back in the Win3.x days, our app used a PeekMessage() loop for a few reasons, including that without it we tended to miss comm port events (these were the days before buffered UARTs.) Of course, with PeekMessage, there was no appreciable system idle time. In late 1992/1993, a new low-power laptop was coming out and our app was OEMed to go into the package. It was reported by the laptop QA team that our app seemed to be keeping the laptop from sleeping and thus was chewing through batteries. It has been a long time so I don’t remember how this was solved. But, I vaguely recall a new WM message that we processed to suspend our PeekMessage loop.
I’d love to be able to write all my code in tax compliant mode, but as a mere developer, if I say to my boss, "I’d like you to send me on a course to help me do X", he will reply, "fine. What’s the business case for us doing X?" If I simply tell him that we ought to do it to play nice and pay our taxes, he’ll just laugh. If I tell him we might save money in the future hell just say that we’ll do it when the need arises.
I agree with MJX. Give users a way to see the apps that are consuming the most power. Then app developers WILL start making power consumption a feature.
Same thing applies to the crashing driver issue from the other day. Just print out the failing driver’s name and manufacturer in big white Letters on the BSOD and watch the problems fix themselves.
The same way regular people are encouraged to pay tax: Legislation and Audits.
Legislation would be OS (or language runtime) features that make being tax compliant the easy or default option.
Audits mean, well, say a laptop runs out of power. It could offer a "Help me diagnose my rapid loss of power" wizard that would analyse running processes for CPU time usage and actually report that a particular application is consuming a lot of CPU (and thus power).
—
Personally I get a warm feeling about paying my taxes. Ultimately however, there isnt a section in my MSDN that collects in one place a checklist of taxes that need to be complied with.
(Additionally I belive that a tax that should be complied with is making your app fit in with the UI of the OS.)
I’m going to put my ruthless hat on and say "beyond making your app survive suspend and resume, power management is not perceived as important".
The last time I did a study in this area:
http://www.iseran.com/Steve/notebook_slides.pdf
I came to the conclusion that network state mattered much more. That’s proxy settings, links being restarted after coming up from suspend, working in places where DNS is absent, staying secure where roaming. That is priority #1 for many intermittently mobile users, and apps are still way behind. Think how recently it is that outlook can handle the network going away? Or how badly Java runs in a network without DNS/rDNS?
Now, tablet users are even less tethered than laptop users, so power may matter more there, But really, networking is job#1.
How do you make developers support this stuff. Formally: marketing need to care, and tell dev to do it. Informally, if you give the developers laptops, make them work on the move, they add mobile support, as suddenly they see what the problems are themselves.
Maybe the Windows Logo program needs an "Optimized for Laptops/Tablets/Mobile Devices" category.
http://www.microsoft.com/winlogo/software/default.mspx
The problem with bluescreens is that any assignment of blame is merely a guess. For example, if driver A corrupts driver B’s memory – e.g. by modifying memory after freeing it – the driver that crashes is B. You can see company B’s lawyers getting all upset when "Microsoft is slandering our product".
A program that fails to support Remote Desktop may fail in more subtle ways than simply "not working". It might hog your VPN bandwidth, causing your session to run slow. A program that fails to support HSM will still run, but it will cause your IT department to go bonkers. Not all failure modes are obvious.
Simple. Provide clear, freely available tutorials for said "taxes". Then make it inconvenient or impossible to use anything else in new development.
How much of a difference can power-consumption awareness make at the application developer level ?, except from doing obviously dumb things like busy-wait loops or reading the CD a KB at time, the average high-level language/framework doesnt really leave you much room for caring about such things, Just like you dont spend time in C# trying to optimize your code to be as much pipeline-pairable as possible, thats the compiler`s job.
Seems to me that the target of this power-awareness campaign should be the people who write the device drivers for the underlying hardware as well as the hardware designers themselves, and the OS kernel team, since this is the level at which it can make a real difference.
Apps can do some things to adapt to power, mainly by being less power hungry when on batteries
-backup less often, or only backup when the HDD is already spun up.
-dont do background indexing, spell checks, grammar checks
-dont animate so much
-dont poll for anything
-use the network less
yet these are often the things that people buy apps for -"background spell and grammar checks", "continuous code parsing and error highlighting", "background email sync". How do you make a feature of stuff that goes away on the move, when the majority of "desktops" being sold these days are mobile?
You can’t, and generally it doesnt matter. Give users a choice between a faster laptop and a slower one with battery life, most people go fo r the fast one. and if you look at the results of my past studies, you’ll see why: they generally only run down their laptop batteries when they travel:
http://www.hpl.hp.com/techreports/2000/HPL-2000-21.html
all you need to do to write power aware apps is "not be an idiot with spinlocks or other CPU-killers" and "handle suspend/resume properly". Divert your engineering effort to deal with the variety of network conditions an app can encounter in a single day, and you end with a feature that is tangibly useful for everyone who uses your app on a laptop, not "0.3% better battery lifetime"
see also: towards an adaptive and context aware laptop:http://www.hpl.hp.com/techreports/2001/HPL-2001-158.html
The best way to make programmers pay their taxes is to make sure the taxman collects. The taxman in this case are the people who are buying and using the software. If they can see that product x is using a lot of power then they are more likely to put pressure on the software vendor to write code that doesn’t use as much power.
I don’t know how feasible it is to do this, but if users don’t know why the battery dies after 20 minutes then they will assume that the battery/mobile PC is rubbish. If they can see program x is eating power like it’s going out of fashion then they can do something about it.
Don’t forget LUA as another tax.
One way of enforcing the "tax" is to make it a logo requirement – you don’t get the Designed for Windows logo unless you follow the rules.
There are limits to how far you can push that particular enforcement mechanism, however
I read Raymond Chen’s post entitled How do you convince developers to pay their "taxes"? with interest….
I found this out by accident, my computer (both CPU and monitor) are plugged to a UPS. Once, I had this program that as soon as I opened it the UPS would scream!!… like it was overloaded, and it was specifically with this application, judging by the application I came to the conclusion that heavy use of cpu cycles (I guess video card cycles as well) make more use of energy, which makes sense, on the end that’s how computers work, with energy
Taxes is not just about features, but the whole polish and feel of your product. A good bit of what’s neede to get developers doing their taxes comes down to developer pride in A Job Well Done ™. Some developers will never care, but, assuming they do:
– Provide tax checklists, relevant sample code and good documentation.
– Be a role model. Fingers can be pointed in any direction, but I’m sure the horrendous VS.NET installer made quite a few people think "hmfff if Microsoft doesn’t care, why should I?"
– Stick to standards. Why should I bother complying with a certain tax, knowing that the next iteration of the system is going to turn it upside down anyway?
– Make a reasonable default implementation. The best way to ensure developers are doing a good job, is when they don’t have to do anything at all.
That’s not a full picture, not even a fair picture… but I hope it helps.
The only way Microsoft can really ‘enforce’ this ‘tax’ is to help customers make more well educated choices about the software they buy. Logo requirement is a huge first step, immediately followed by tools to make it easier to see failures on the part of applications to do the ‘right thing’. Make it obvious which application is drawing down the battery, and consumers can make better choices.
It’s also worth pointing out that a lot of these ‘taxes’ only apply to subsets of the market. If sales sren’t hurt by lack of support for 64-bit or HFS, then developers can and should spend their time on more profitable things.
"If sales sren’t hurt by lack of support for 64-bit or HFS, then developers can and should spend their time on more profitable things. "
Just thought of this, and it’s worth mentioning in this context.
I recently read an article discussing AutoDesk’s financial performance over the last 8-9 years. Apparantly, they suffered in the late 90’s because they made their software Year 2000 compliant too early. Their sales slowed because customers were diverting lots of software dollars to upgrade software that had to be upgraded, rather than AutoCAD, which was Y2K compliant. In that sense, they suffered for paying their ‘taxes’ early.
Davie:
>>Same thing applies to the crashing driver issue from the other day. Just print out the failing driver’s name and manufacturer in big white Letters on the BSOD and watch the problems fix themselves.
Is that the name of the driver that crashed or the one that overwrote the crashing driver’s memory, causing the crash?
I found this somewhat ironic, because a relative of mine works for a company that makes cell phones (both hardware and software), and he had somewhat the opposite problem:
People writing software for the phones were writing code that ran in a tight polling loop to test certain conditions. My relative told them that made the phones hotter, which is a problem because cell-phone users get freaked out when their phones get warm; but they just didn’t care.
Finally he changed his pitch — he pointed out that when they wrote this kind of code, it shortened the phone’s battery life. Suddenly everyone started paying a lot of attention. After all, at a cell-phone company, battery life is a big deal.
Add a Energy Consumption column to the Task Manager. Turn the column on by default for all mobile computers. The value in the column should be reported as the number of hours:minutes of battery life an application has drained.
Logo requirements are a good way to deal with this, but only if getting the logo is important. When Win95 was new, my company worked hard to get our latest products certified because our sales department said it was critical. A year later, they said it wasn’t worth bothering because they could find no discernable effect on sales.
If MS can make the logo certification mean something to the bottom line, then making this part of the certification is a good idea.
QAck: This assumes that the "Energy Consumption" of an app can be meaningfully computed in the first place. An app that writes to the registry once an hour eventually wakes up the hard drive when the registry lazy-writes. The cost of writing to the hard drive depends on whether the drive is spun-up already or not. How do you charge it?
Well, you could always go the Apple route. In other words, if developers don’t "pay their taxes", their software will simply stop working properly in the next point release of the operating system.
In return, you get a high-quality "software ecosystem" plus a number of other bonuses: disgruntled developers, negligible market share… no, wait. Going the Apple route might not be such a good idea after all.
It depends entirely on the software package but in some cases it can be a deal breaker.
I used to have a ‘mobile’ and ‘plugged in’ profile on my notebook where mobile disabled things like auto anti-virus checking or background defragmentation runs.
When I tested a trial of a competing defragmentation product and found that it had a special setting to prevent any defragmentation runs when operating on battery power I switched over to the competing product and never looked back.
There’s probably little you can do to force others to develop with power conservation in mind, but highlighting and promoting software packages that do go the extra mile and scale down on a laptop running on batteries will force other to follow suit.
As for assigning a number to it, you can do that yourself already. Just monitor an application’s CPU usage and disk access rate. Sygate’s personal firewall for instance will constantly perform disk access (with no way to turn that off), effectively preventing the hard disk from ever spinning down to conserve power.
Several of the commenters had it exactly right. The most important thing for you to do is to tell me what I need to do. Give me a checklist with things I need to support, give me a tutorial on how to support them, and give me a tutorial on how to test this support.
I have time to do these things right. I don’t have time to follow everything that MS publishes to figure out how each new feature effects my code.
I specificallly develop for and test against 3 of the 8 items you listed. Of the rest I didn’t know they were likely to be a problem, or in the case of Hierarchical Storage Management didn’t even know it existed or what it meant.
Other examples of taxes are the accessibility requirements: large fonts (120+ dpi), high-contrast, keyboard navigation for *everything*, IAccessibility for custom controls. Not only is it difficult to make a business case for following through on these, but it often runs counter to the designers’ demands.
One problem with tax paying is that developers rarely have control over the entire product anymore. Just as end-users aren’t going to choose one spreadsheet over another based on power requirements, developers don’t pick third party components based on how streamlined they are. Top-level requirements drive the marketplace (at least until there’s parity among the competition).
I’d be interested in reading more about power usage in particular. Obviously unnecessarily spinning up drives and using a (wireless) network connection wastes juice in the cells, but are there things we can do with processor utilization and working set size that make enough of a difference to care about? Does the spell-checking thread in the background degrade by battery life more than doing a single pass before I save my document? Does sparking up the 3D GPU to do Avalon-like effects with ClearType-ified outline fonts consume more electrons than plain old 2D GDI operations with bitmap fonts?
It seems to me that power management is different from most of the others in that list.
Most of the others *could* quite easily be a deal-breaker – for example, I do a LOT through Remote Desktop and the rest of the time I’m using FUS – if software fails to work correctly in either of those scenarios, I’ll get other software. Same thing goes for people who use roaming profiles or 64-bit – if the software fails to work in the configuration they use, then they’ll use something else.
Power consumption, on the other hand, isn’t clearly associated with the app in question and it’s a quantitative rather than qualitative thing – it’s not like the app will simply fail to work when running under battery power. So even people who are affected by it won’t necessarily notice and change their software.
I agree with others here that the best thing to do is to demonstrate clearly which app is at fault for power consumption. Perhaps a little bubble coming from the systray saying "Foo is using an excessive amount of battery power. Should I close it?" and an option to ignore that application in future. Excessive would be defined differently for background applications versus interactive foreground ones – a background app should be *very* conservative about power consumption where an interactive one can be somewhat less so; hopefully the OS can at least pick a good heuristic to determine which is which.
Good question, though :)
I think some people are a little confused over a few of these "taxes". Some of the taxes (I’ll stop the inverted commas now) are big ones like power consumption that may take quite a bit of planning to achieve. Most are small little things that people just forget to check. For instance the roaming profiles, hierarchical storage and multiple monitors taxes are simple to fix. Most of the time it’s a developer not thinking "what if the user has this" or "what if the API call errors" (in the case of the HSM problem [or at least the problem in the main body of the post Raymond links to, maybe he means more than just the API call problem]) and so like someone suggested a simple check list would help you out no end and if doesn’t take a whole lot more developing time, most of the time it’s a couple of extra lines of code as they’re just simple checks.
The problem is that there are many of these checks. While a good developer will always think "I’d better check that error code" and "I’d better make sure my window doesn’t move onto a new monitor when I think I’m getting it off the screen" there will always be something to miss, and the problem with a check list is that a developer (or indeed the list compiler) won’t want to go through every little thing for every possible type of inadequate (or quite adept, even) developer.
Building it into an IDE or code checker also won’t work in practise because there are many ways in which the problem can arise. When it’s just making sure the error code is checked after calling an API maybe it can be built into a code checker, but it can’t be included in an IDE in a template because not everyone (and in fact maybe few people) may even use this API, you can’t just include it in a template when most people aren’t going to use it. It will be redundant and totally out of context.
When it comes to making sure that you aren’t messing about with window positioning or whatever there’s no way a code checker or IDE can help you.
The bottom line is that while no-one should ever have to pay taxes, they are a necessity and people have to. People just need to think before steaming ahead and doing something that just happens to work on *their* set up.
Having said that, especially about the list of taxes being intractable, people make mistakes, and it’s blogs like this one that help people to see the bigger picture.
The way to get them to pay taxes is to make it very hard for them not to.
How? Give them a development environment that isn’t built on top of 15 years of hacks and workarounds. If you want people doing multimon right, then give them an environment that doesn’t have most of its code geared for single monitor. If you want them to put files in the right place, give them an environment where it’s easier to use relative paths from a profile directory rather than working with absolute paths.
Basically, it worked for mac. Give the people the sandbox you want them to work from and they’ll work from it. Make the old stuff run in emulation and move it away from the new stuff.
Now of course, what I’m talking about isn’t terribly practical for Microsoft in the short term, but it’s still the correct solution.
(I’m sure I clicked "Remember Me?" already. Something’s odd with the cookie handling between Text and Firefox, maybe. Anyway.)
It’s funny you mention multiple monitors with the implication that MS is ahead of the game on this. The new Anti-Spyware beta is too irritating to use on my system because it’s not multi-monitor aware – I have a 1025×768 laptop screen and a second, 1280×1024 monitor on the LEFT HAND SIDE, and MS-ASB sticks a little utility window at the top of the second monitor. Irritating, so I haven’t bothered installing it since I rebuilt my machine last week. Spybot S&D and LavaSoft Adaware will do for now.
Meanwhile, other software is useless with this setup. Irfanview, an otherwise excellent free graphics viewer, barfs if you try making the window larger than the smaller desktop size; it just won’t repaint. The programmer says it’s not a priority for the near future, which is a shame.
And as a programmer, I’ve discovered a few bugs in either Delphi or Windows – I don’t know which. If you tell a form to position itself at desktop-centre, it sits straddling the RIGHT HAND SIDE of the main screen, which in my case is The Wrong Thing. Basically it assumes the second monitor is to the right of the main monitor. Silly, and I DO understand, and I’m not saying anyone is incompetent, because I’d never have thought of it. But it goes to show…
"Give them a development environment that isn’t built on top of 15 years of hacks and workarounds."
Checked builds will do this, which is a good thing for devs and testors to use at least occasionally. They’ll reveal a lot of incorrect assumptions very quickly.
When MS pushes AD, the world slowly hops on board the AD bandwagon. When MS pushes security, the world reluctantly gets behind them in their own software. And so on; making something a company-wide and system-wide priority is the best way MS can effect change. All the taxes that make something safer, easier to use, and better behaving need constant encouragement combined with easy-to-access lists and information.
I like the one about VS presenting a default checklist of the most important housekeeping TODOs.
I find the problem with paying these ‘taxes’ is the same as paying real taxes; documentation to correctly fill in all the required fields is difficult to find, often buried or misplaced and occasionally completely inaccurate not to mention you sometimes need the ability to read the document author’s mind as the information provided sometimes leaves one scratching their head.
If you want developers to do the right thing then I believe MSDN needs a major overhaul. I often read about how you, Raymond, submit changes or corrections to the MSDN team and they never carry through. If MSDN was improved and information made easier to discover I think overall more people would pay their ‘taxes’
Adrian,
Giving developer different hardware is likely to give the company lots of problem you know? And not mentioning giving a programmer inconvienent working enviroment will make them far less productive.
Company bosses are willing to pay for having programmer have the same hardware for development. In case any of the desktop fails we can quickly plug off the harddisk rack and plug it in a backup one, the hands the faulty one to the technical department for investigation. But if you say I have to persuade bosses to set up different config for development and slow down the development process, it bet they’ll just say "leave it to the testers" and "don’t bother until the software ships".
First maybe we should figure out which taxes we want developers to pay. There was a public discussion on a Dell forum a while back, because owners of Dell notebooks and USB hard drives found that their drives weren’t spinning up when connected to the notebooks. Dell’s public answer was that this was a deliberate design decision in order to extend battery life. Hard drives temporarily draw extra power at the moment of spinning up, the USB standard doesn’t really allow it, but most vendors do allow it. Dell’s stated reason for sticking to the standard in this case was the intention of preserving battery life.
So what does this mean? Well this: The machines’ owners and users don’t get to decide how they’re going to use their batteries. Dell decides. One can only wonder why Dell didn’t decide to shut off the screen’s backlight and the CPU in order to preserve battery life.
Now sure drivers and services should be a bit friendlier. When the user wants to configure the machine to preserve power, all drivers and services should agree.
When Windows 2003 refused to hibernate on account of the Routing and Remote Access service running, I’m glad it told me. It’s a nuisance to open up the Services panel and stop the service, but at least I knew what to do. I’m sure some years ago Windows 2000 also told me why it was refusing to hibernate. Why doesn’t XP report what its reason is when it refuses to hibernate, that is really a pain. So one of the taxes that should be imposed on developers of Windows XP is to give the user information that the user needs in order to get the job done.
This brings up a recent experience I had with my mobile phone/PDA. One of the new applications available through the telephone company was a new app which simplified internet access. After installing the application, the phones battery would drain before lunch time, without a single call made. After the application was removed, battery life was restored to a more respectable level. (I’m talking about Motorola and 3/Hutchinson). Clearly a case of developers not concerned with taxing the system. These guys will no longer get any business from me.
Another way to make sure the developers pay the taxes is to tax their development environment. Give them Windows 98 laptops with 128 MB RAM, multiple monitors, large fonts in 256-color mode, offline storage, a flakey network connection, roaming profiles, and no mouse. If your developers don’t mutiny, they’ll deliver apps that handles those constraints.
Have a team of developers? Give each of them a *different* configuration, and you can cover a lot of problems.
On NT-based machines, developers should have a second account without Administrator privileges.
"My Documents" and "Program Files" made everyone deal with long file names with spaces. Giant hard drives made people fix their free disk space checks. Windows 95 made us erradicate our 16-bit assumptions. Giving a developer multiple monitors will fix those tooltips-on-the-wrong-display bugs faster than any number of reports in the bug database.
Test labs with different configurations are useful, but nothing gets fixed faster than a bug manifest on a development box.
Additional taxes:
– LUA (as mentioned above)
– Deployability (mostly proper setup)
– Internationalization
– Accessibility
I think one of the most important "taxes" is how to handle Administrator rights. Some applications require Admin rights, while the need for it is nowhere in sight.
Tell them that in the long run, its cheaper for them.
I am building a computer – and looking hard at the Pentium and AMD processors when low and behold – I come across several articles that discuss the Pentium M chip. I specifically want a quiet computer and low and behold – found a miniATX motherboard to support it.
In that research – I learned the the latest Pentium’s from Intel draw enough power to light my house whilst the Pentium M chips are meager in comparison. Initially, the M chip is almost twice as much, but relatively speaking – its not so bad. $200 extra now – maybe I’ll save $10 a month in electricity – so I’ll recoup my cost in 20 months … or less (my computer will probably be obsolete by then ;)
I think one possible way to get people to pay taxes is to reinforce where their tax dollars are going. Break into my car or house a couple of times – and I’ll soon realize I need to pay for my neighborhood police force.
Then again, taxes for something I think irrelevant … well, that’d be a harder sell.
*Transparency* begets trust and mutual respect.
Simple. Provide facts that explain why this is an issue, then let the individual decide. That’s the best you can do. The key point being that one provides the information along with concrete and extensive examples. The less that is assumed about the reader, the better (more objective/netrual).
Perhaps MS could include some class libraries and application frameworks that have the taxes prepaid.
For example, for C++ developers you have a hypothetical application framework called "Microsoft Foundation Classes", and default applications built with this imaginary "Microsoft Foundation Classes" framework would automagically pay the taxes, leaving the developer to concentrate on what he’s trying to do instead of a lot of housework.
VMWare or other virtual PC type software would help – developers can have a "standard" environment, and easily test with a range of operating systems and hardware setups. Things like video and sound cards can easily have a different combination on every developers PC simply because if that ever causes a problem then the software is buggy and needs fixed immediately.
One more vote for adding some of these things (esp. power usage) to the windows logo guidelines. Even people who don’t want to get the logo can at least use it as a list of what’s generally expected for good software.
As for persuading people to "pay" the taxes – educate the users on the benefits of security and reliability. For years, all UNIXes have had locked down user accounts, and most software is written assuming that will be the case. This is only recent for Windows home users, and is already starting to show up a lot of badly written software. Personally I like the idea, and am happy to write software that plays nicely – figuring that either the competition won’t get ahead of me on that or perhaps I’ll come out better than the competition when people can’t even install their software. ;) Given that the end result actually is better for users (and even the Linux fanboys can only say it’s about time, rather than criticise the design), it’s one thing I won’t whine about "having" to do because of Microsoft.
Tuesday, August 23, 2005 9:49 AM by Luther
> Break into my car or house a couple of
> times – and I’ll soon realize I need to pay
> for my neighborhood police force.
Wow, where do you live? In most of the world if someone breaks into your car or house a couple of times then you’ll soon realize that the taxes you’re paying for your neighbourhood police force are completely wasted. They’ll take action against someone who steals 1% of the wealth of a rich and powerful organization, but they’ll file and forget a report against someone who steals 110% of the assets of an average joe, and they’ll do nothing when someone steals $10 each from millions of average victims.
(That 110% isn’t an exaggeration by the way. Have a bank account and have a credit card that will soon be due, and when your money disappears you still owe on the credit card. Or hire a lawyer, or even sue without a lawyer and you still have to pay court fees but the thief still gets to flout the court order with impunity.)
Sorry for being tangential to the topic. It just happened to be a hot button. I do pay my taxes but just like everything in life no good deed goes unpunished.
http://blog.seattlepi.nwsource.com/microsoft/archives/005571.html
I remember recommending (I was a temp…
I definitely agree with the sentiments that the OS should make as much as possible automatic.
If I’m writing a word processor, I should be worried about, well, word processing. I shouldn’t have to worry so much about dual monitors or power consumption. I may be an expert on word processing but know nothing at all about the proper method to implement multiple monitor support or how to optimize power consumption or handle hibernation. All I wanted was a word processor!
These things should be abstracted from the application. At most, the application should have to set a few values that say ‘Yes/No, I do/do not want to support feature X’ and ‘Yes/no, I do/do no want to toggle feature X.’
But if I have to implement from ground up support for roaming user profiles, Fast User Switching, Hierarchical Storage Management, multiple monitors, Remote Desktop, and 64-bit Windows, I’m probably not going to do it.
Is it even <em>possible</em> to detect which app is consuming the most power?
For hardware, it doesn’t seem to be a problem — just check the wattage running into each component. But how can you tell which application is responsible? CPU cycles might be one thing, but maybe it’s video or networking or some other aspect. In some cases the app might be calling into the WinAPI, so the "process" that is using power isn’t even the application itself.
When developers don’t pay their "taxes", the users pay – in lost productivity, increased support costs, and now, loss of data.
Another "tax" is security/reliability. So many people claim it costs "too much" to write secure code. What is the cost of cleaning up after a network worm as the result of a buffer-overflow bug?
As for the Dell USB power limit, the USB spec prohibits devices from drawing more power than the host gives it permission to. Most portable USB-powered drives draw more power than they report to the host – in other words, they lie. Some drive manufacturs play so loose that their drives damages the circuitry in the laptop.
I, for one, welcome Dell’s decision to limit power. It is the USB drive manufacturer’s responsibility to follow the USB spec and not damage laptops.
Tuesday, August 30, 2005 9:04 PM by James
> Most portable USB-powered drives draw more
> power than they report to the host – in
> other words, they lie.
Oh, that is a serious matter. Dell’s public statement on the issue didn’t say that, and I wonder why. (Or can I figure out why … Dell’s site also offered a USB-powered drive, and maybe Dell couldn’t say publicly if the drive did this kind of thing. I wonder if the same issue arose when connecting the drive to desktop USB ports.)
> I, for one, welcome Dell’s decision to limit
> power.
Yes, if Dell is limiting power to the level that the drive claims it will draw, then that is the right thing. I wonder why their public statement didn’t word it that way.
> It is the USB drive manufacturer’s
> responsibility to follow the USB spec
Agreed. But most computer vendors offer some built-in extensions, just as most compiler vendors offer extensions to standardized programming languages.
P.S. It actually costs extra for Dell to limit power on its USB ports, because it (usually) requires an additional chip to detect the true power drawn by the device and limit the in-rush current. Most USB ports just have a slow-acting fuse on its power line. Take a look at your garden-variety USB 2.0 add-in card.
All the more reason I thank Dell for doing the Right Thing.
Tuesday, August 30, 2005 11:59 PM by James
> P.S. It actually costs extra for Dell to
> limit power on its USB ports
Thank you for the information.
Of course now I wonder even more why Dell’s public statement was worded the way it was, instead of giving the important information that you did and making a really good impression. Well, that’s their problem, all I can do is wonder.
By the way, in each of the two bus-powered USB adapters that I now use, there are separate cables to draw power from one USB port and make a full USB connection with a second USB port. If connected in that order then it works, even when connected to a Dell. So is Dell really detecting and limiting in-rush current on each port separately instead of at the hub?
I do know that
– I want my PC to turn off quickly
– I want my PC to turn on quickly
– When I turn-off my PC I dont want to get any of those messages saysing ‘rundll32.exe is still going, zap it now or wait until this blue-boxy progress bar fills then we’ll zap it for you’
– I dont want to sit and watch my Laptop PC power down so that I am confident i can close the lid and put it in my bag knowing it is ‘off’ and I’ll have some battery power when it turns on.
Will this affect my purchase decision?
Probably not – I wont trust it until I’ve used it.
Will this affect my ‘brand’ (OEM/OS/other-software) loyalty. Very definitiely. Especially if I know who broke my experience. Will this affect what I tell my friends about my experience? Oh, yes, I’ll notice the difference…. …with time I’ll stop watching a power-down that always works and is quick…
Let’s make it really clear what servie the ‘Dev’s who dont pay their taxes work for. rundll32? who’s that, name the player…. let me know its Application X that is making me wait….
sales of application X may well drop…
Hope I make sense :-)
I’m not a dev, as you’ve probably guessed…
Most computer users are familar with the adjective "power". "I want a more powerful PC," where the power…
The Old New Thing: Practical Development Throughout the Evolution of Windows
PingBack from http://www.gregcons.com/KateBlog/TheOldNewThingPracticalDevelopmentThroughoutTheEvolutionOfWindows.aspx
PingBack from http://www.dwightgunningcom.textdriven.com/stuntshow/?p=135
At Netstore we've spent quite some time over the last six months implementing a custom diagnostics
It looks so nice at first.