Yahoo CEO Marissa Mayer's decision to end telecommuting, which ignited a firestorm of criticism.
There was no firestorm, just whining from unproductive Yahoo employees and media parasites.
Perhaps they didn't get the memo, but Google (which is what Yahoo wishes it was, and is where every Yahoo employee wishes he/she was working at) doesn't allow telecommuting either. Marissa was just putting in place policies that worked for Google.
Perhaps Yahoo should do as Google on this also: opening facilities on third world countries to avoid paying too much on salaries. What do you think?
(I think it would be great! I live on one of these third world countries!)
Billions of dollars can be deactivated by a simple PEM.
You know... the bombs that emits an electro-magnetic pulse that disables everything that are digital...
They are so simple to build that USA would restrain itself from use them, as the enemy would easily figure out how to build one by analyzing the bomb's scraps...
It's been pretty obvious from the start that Koh was in the tank for Apple. I suspect at this point, she's worried about what the appeals court might have to say about her conduct, especially if they can't find grounds to overturn her verdict.
If that was the case, how come shes still practicing law? In other civilized countries we have laws against judges preciding over cases where they have personal stakes in the outcome of the case - She should receive the judicial version of curbstomping if the bolded is correct.
Yep. But on these same civilized countries, one must first file a denounce. The denounce is studied and, if accepted, a lot os legal proceddings (including a trial) is needed before the judge is discharged from his/her duties.
I don't see no denounce being filed. Yet. But things can change - mainly by the fact that Samsung's case didn't had a very... up to the letter... treatment under this judge's rule.
I just don't se the words "maximinize revenue" as the best choice for what you are describing - but granted, I'm not a native English speaker. This could be due cultural differences.
You call it ape, I call it monkey. But if "it" calls himself "Cezar", just one of us will get killed.:-)
They're trying to maximize revenue from every game, which on the surface seems like a good thing for them as a company. Unfortunately it's incredibly shortsighted.
They, you, me and everybody else are trying to maximize revenue from every [insert your selling product here].
This is allright while the customer has the choice to give them the finger and go buying the thing/service/whatever from someone else.
It's when you get a lockout and starts to abuse the revenue over your customers that things go bad.
Just offer free and paid in game action like D3. It's fine if you buy the game and then want to go buy the the new gun for $20, as long as that same gun can be earned by someone playing the game for free.
I don't buy it. As a purchaser, I expect the same experience than the micro-transaction version.
I would not mind someone geting a hard to get issue for 20USD on the micro-transaction version, if I (who paid premium on the retail version) could get the item by a cheat code and have the same experience.
As long you you didn't pay for the "retail" version (a.k.a. DVD / Blueray delivered ones), I don't see a problem. The developers has to be paid somehow, and if some people wants to pay for their games this way, no problem.
I can't see the link between my opinion and your conclusion.
I didn't ever touch the used itens problem. There's nothing in my post that can be used to even imply I'm against the First-sale Doctrine. Are you trolling?
By since you touched the matter, if you paid the "full retail" DVD/Blueray/whatever, then the game is yours to do what you want - including selling it for less or for more if you find someone willing to buy it from you.
I assume you are not looking to repeal logic and/or grammar, are you?
As long you you didn't pay for the "retail" version (a.k.a. DVD / Blueray delivered ones), I don't see a problem. The developers has to be paid somehow, and if some people wants to pay for their games this way, no problem.
But if I pay the full retail price, I expect to be able to enjoy the game in full experience. Paying twice for the privilege of playing an already paid game is not an option for me. It shouldn't even be allowed, at first place.
You make some good point. Howevr, imagine the following not uncommon scenario:
Very common, if you ask me. Mainly where I live, as it's very common to be underpaid, being changing jobs the only way to get a rise on your incoming.
1. A small number of experienced developers starts a project 2. The devs choose to build their own framework for the reasons you describe 3. PM wants ever more features, the project grows, more developers join 4. All new code is build on the framework made in step 2 5. Framework is extended 6. Original devs leave
DON'T FIRE THE SENIOR!
The very mitigating factor for the "problem" you are trying to avoid is the biggest cause of the problems you fear!
No matter what they told you on the Rational University (yeah, I have some fancy certificates) - leading developers are not easily replaceable, unless your system is something so well known and easy to reproduce that you should be buying it from some software factory instead of reinventing the wheel yourself!
So now everyone can use the framework, but it's original devs stopped maintaining it. Everyone know how to use the framework, but nobody knows its inner workings well enough - we have a custom, still lightweight framework tailored for the job, but nobody's maintaining it. The worst of both worlds, a framework maintained by people you can't rely on to understand it and fix its bugs, and the initial investment to build it in the first place.
Been there, done that. I inherited an old and buggy framework in one of my tasks as a contractor.
However, I'm a very experienced, senior, developer. And since the framework was tailored for the very task it was meant, it wasn't big enough to be beyond be. It took me 1 or 2 days to understand the framework, then I gone for fixing it. Since the previous developers were a very professionals ones themselves, the documentation was good. Not perfect, but good enough to help me on the task. I had even time to do some refactoring, in order to eliminate a external dependency from a old (third party) framework that was not used anymore.
But don't take this history as the common ground. Good documentation is not something easily found. God knows it's not always I can convince the client that he should allow me to "waste time" writing good documentation.
In the end, you're right, there is no clearly defined criteria for which approach is better than the other, both ways has a very good chance to bite you in the ass. My perspective however, not as a developers of production systems but a software testing engineer (writing code to break other people's code;)), what I see is bugs, bugs everywhere.
Hey, I did that too!. Long before I gone Senior on software development, I was a black box tester. While being trained to white box testing, I got a chance to do development and jumped on it.
I cut my teeth on the Rational Suites (it was just before IBM's acquisition). The Rational's Test RealTime was something very impressive at that time! (I hated ClearCase/ClearQuest).
As a side effect, I always tried to be in good terms with the testing team. In the very, very few times I had to say "no" to them, I've heard.
Hardly any new feature, however straight forward it appears in its original specs, that's not can of worms of new and exciting issues. That's why I'm very skeptical of using new code when existing, already tested code exists.
Now I understand better your point of view. You're used to environments with long lifespan. You can test the software now, and be sure it will work next year because you know that the environment will not change unless you (or someone you thrust) approve the change.
Not many companies can afford such control, and some product niches just don't allow it (I was a embedded developer for the automotive once).
For example, I'm tired of catching [insert your favorite MacBook manufacturer =P here]'s mistakes on their protocols implementations. Why? Because they simply refuse to acknowledge their existence!
Since I already implemented a Bluetooth Protocol for a embedded system, I KNOW how to debug and catch this quirks, but who am I to dare to say Apple is wrong?
"The implementation is not wrong, it's just not right." - yeah, they shoved it on me.
This line of thinking is the rule on this industry. No one is accountable for anything, and if you have money enough, you can say anything that it will stick.
Sure, throwing some huge framework on a small problem is not a sensible approach. Seems like a no-brainer. But where to draw the line? A real life application constantly grows, and has a good chance to eventually use a growing percentage of the features exposed by a given framework.
That's the point! THERE IS NO LINE!.
The decision is made, mainly, by environmental and political questions (and not technical!). How much time do you have to deliver the first prototype? How much years the system is expected to be used? The running environment is expected to change in the near future? How much money the client is willing to shove on the project (seniors developers are not cheap!)? Do you thrust the client will not change his mind in the middle of the project?
If you know your application will not outgrow its initial specs (in an unexpected way), it might make sense to opt for an own framework.
And how you know that your application will outgrow in a expected way, so you can be confident that your framework of choice (at the moment!) will be the right one in the years to come?
This is a catch-22 situation. Since you don't know where in hell your system will end up computing bugs =P, you don't now neither if the framework you're using will not bite you in the arse.
So, you will be bit in the arse no matter what, using a custom framework or a "standardized" one from third parties.
Make the choice that makes sense at the moment. You can't save the future, make the best you can do in the present.
My personal experience, however, is that developers too often opt for their own solutions, maybe due some kind of not invented here syndrome, and duplicate a lot of work.
My personal experiente says you're getting it so wrong. (Experienced) developers like their own solutions because, by worst they're, they will solve exactly the problem they have under their eyes without having to learn a lot of "possible solutions already made" that almost solve such problem (making him patching the problem to fit the solution).
More times that I would find reasonable I spend more time surviving the framework then using it. Sometimes it worths the pain (you're right too), but on a lot more, it does not.
And since I'm paid for the problems that I solve NOW, and not by the problems that I will not provoke TOMORROW, it's easy to understand why good and experienced developers tends to "reinvent the wheel". It's better for us to have a so-so wheel that fits perfectly our wagon, than a perfect one that makes me change its fscking chassis (for the same price!).
That is bad in a lot of ways,
Please don't be part of the problem you complained in your first paragraph. Don't use subjective arguing.;-)
as a well maintained framework with multiple developers and documented bugs is always preferable to completely new code.
Using a giant framework, built and maintained by people that you don't know neither can rely on. and that you don't understand how to fix can cause a lot more of trouble than you think. Can I mention phpnuke?;-)
Usually, frameworks are not written and maintained by one person. And thus, you are free to worry about your own code and its bugs, and have others worry about the framework's bugs (within reason, for crucial bugs you will of course need to worry about finding a viable workaround). Code reuse is a good thing, and no single person is smarter than > 1 person.
Also, frameworks do not usually change completely in less than a year, and the change that does happen is gradual - as long as you keep the framework you use up to date the learning curve is flat.
Yeah. Wordpress is the most secure platform to develop on, right?
The bigger the framework, more useless (for your current application) code on it. Code that can have bugs itself, and since you didn't wrote the code, you're just screwed up unless fix it yourself (what you probably would do faster if you were using your own).
If frameworks would usually change in less than a year, we would probably had less problems. But you're right, frameworks don't change in less than a year. Browsers, Operating Systems, Computer et all, all of them do. A Service Pack, a Browser update, a little permission change on some obscure file, and you can't guarantee your code will run fine anymore.
And you alone just can't test that huge framework on every change that happens. You must thrust God that everything will be alright.
Risky Business. God is not a Software Engineer.
Jokes aside, please read carefully what I said before: There's something very wrong when you spend less time building your own framework than learning a well known and stablished one to do your task.
Even Wordpress has a lot of very good uses. But I would not use this beast for my personal tech blog, God Damnit. Why should I expose my entire site to the Wordpress exploits just because a personal blog? Spend some hours writing that static HTML pages and it's done! Learn to use CSS correctly (what you need to know anyway) and you will not have problems when you decide to change your theme.
Frameworks is not inherently evil. But using a huge one just for the sake of using it is dumbness.
When you do real programming, do you implement your own printf()?
Because they needed to fit an operating system in 14KB.
Yes. When I wrote a Operating System tool (for a embedded application using Freescale's FlexOS), I did. Since I didn't needed a full blown printf implementation, I was able to save some precious kbytes, invaluable resource to be spent on code that make the user happier.
Look, pal. Read carefully what I said before; "When you spend less time writing your own framework than trying to use an already stablished one".
In absolutely no moment I even implied that every framework is evil.
Frameworks to do simple things may be stupid, but it's just as stupid to write your own code every time too.
Being that the reason that old school programmers make their own frameworks?:-)
There's something very wrong when you spend less time building your own framework than learning a well known and stablished one to do your task.
You can argue that a well known and stablished framework will save time on the long run. But I will counter-argue stating that this is only true if the guy knows the framework by heart - otherwise he will be screwed up on every single mistake did by someone's else.
It's better to "waste" a little time now and in every project in the future, than to waste a huge one now and then in the hope that somewhere the future I will be able to throw up a new system every week without hassle - what's is not going to happen anyway, because in less than a year everything is changed, and things will start to break, and the cycle starts again.
More likely a margin call. If he borrowed against his sinking stock portfolio, at some point he would be forced to liquidate it to satisfy the terms of the loan.
The Progress Bar loses his functionality when Windows 96 start to use it just as something that moves on the screen. No real processing is associated with the Bar or Animation activity!
On the other hand, there are programs that do it right! Unfortunately, one of the best examples I have is a console Linux program: The Midnight Commander - so, very few people nowadays is exposed to a correctly written Progress Status notifier mechanism...
Slashdot Mirror
Yahoo CEO Marissa Mayer's decision to end telecommuting, which ignited a firestorm of criticism.
There was no firestorm, just whining from unproductive Yahoo employees and media parasites.
Perhaps they didn't get the memo, but Google (which is what Yahoo wishes it was, and is where every Yahoo employee wishes he/she was working at) doesn't allow telecommuting either. Marissa was just putting in place policies that worked for Google.
Perhaps Yahoo should do as Google on this also: opening facilities on third world countries to avoid paying too much on salaries. What do you think?
(I think it would be great! I live on one of these third world countries!)
Billions of dollars can be deactivated by a simple PEM.
You know... the bombs that emits an electro-magnetic pulse that disables everything that are digital...
They are so simple to build that USA would restrain itself from use them, as the enemy would easily figure out how to build one by analyzing the bomb's scraps...
iPad Mini is using a new revolutionary engine based on the Replica 1. :-)
How we would now if it's really our hour if we don't try it? ;-)
I'm sure they will be remembered, but hopefully not missed! :-)
It's been pretty obvious from the start that Koh was in the tank for Apple. I suspect at this point, she's worried about what the appeals court might have to say about her conduct, especially if they can't find grounds to overturn her verdict.
If that was the case, how come shes still practicing law? In other civilized countries we have laws against judges preciding over cases where they have personal stakes in the outcome of the case - She should receive the judicial version of curbstomping if the bolded is correct.
Yep. But on these same civilized countries, one must first file a denounce. The denounce is studied and, if accepted, a lot os legal proceddings (including a trial) is needed before the judge is discharged from his/her duties.
I don't see no denounce being filed. Yet. But things can change - mainly by the fact that Samsung's case didn't had a very... up to the letter... treatment under this judge's rule.
I see your point. You're right.
I just don't se the words "maximinize revenue" as the best choice for what you are describing - but granted, I'm not a native English speaker. This could be due cultural differences.
You call it ape, I call it monkey. But if "it" calls himself "Cezar", just one of us will get killed. :-)
They're trying to maximize revenue from every game, which on the surface seems like a good thing for them as a company. Unfortunately it's incredibly shortsighted.
They, you, me and everybody else are trying to maximize revenue from every [insert your selling product here].
This is allright while the customer has the choice to give them the finger and go buying the thing/service/whatever from someone else.
It's when you get a lockout and starts to abuse the revenue over your customers that things go bad.
Just offer free and paid in game action like D3. It's fine if you buy the game and then want to go buy the the new gun for $20, as long as that same gun can be earned by someone playing the game for free.
I don't buy it. As a purchaser, I expect the same experience than the micro-transaction version.
I would not mind someone geting a hard to get issue for 20USD on the micro-transaction version, if I (who paid premium on the retail version) could get the item by a cheat code and have the same experience.
As long you you didn't pay for the "retail" version (a.k.a. DVD / Blueray delivered ones), I don't see a problem. The developers has to be paid somehow, and if some people wants to pay for their games this way, no problem.
So you are against the First-sale Doctrine.
I can't see the link between my opinion and your conclusion.
I didn't ever touch the used itens problem. There's nothing in my post that can be used to even imply I'm against the First-sale Doctrine. Are you trolling?
By since you touched the matter, if you paid the "full retail" DVD/Blueray/whatever, then the game is yours to do what you want - including selling it for less or for more if you find someone willing to buy it from you.
I assume you are not looking to repeal logic and/or grammar, are you?
As long you you didn't pay for the "retail" version (a.k.a. DVD / Blueray delivered ones), I don't see a problem. The developers has to be paid somehow, and if some people wants to pay for their games this way, no problem.
But if I pay the full retail price, I expect to be able to enjoy the game in full experience. Paying twice for the privilege of playing an already paid game is not an option for me. It shouldn't even be allowed, at first place.
They hired Robert T. MORRIS.
You make some good point. Howevr, imagine the following not uncommon scenario:
Very common, if you ask me. Mainly where I live, as it's very common to be underpaid, being changing jobs the only way to get a rise on your incoming.
1. A small number of experienced developers starts a project
2. The devs choose to build their own framework for the reasons you describe
3. PM wants ever more features, the project grows, more developers join
4. All new code is build on the framework made in step 2
5. Framework is extended
6. Original devs leave
DON'T FIRE THE SENIOR!
The very mitigating factor for the "problem" you are trying to avoid is the biggest cause of the problems you fear!
No matter what they told you on the Rational University (yeah, I have some fancy certificates) - leading developers are not easily replaceable, unless your system is something so well known and easy to reproduce that you should be buying it from some software factory instead of reinventing the wheel yourself!
So now everyone can use the framework, but it's original devs stopped maintaining it. Everyone know how to use the framework, but nobody knows its inner workings well enough - we have a custom, still lightweight framework tailored for the job, but nobody's maintaining it. The worst of both worlds, a framework maintained by people you can't rely on to understand it and fix its bugs, and the initial investment to build it in the first place.
Been there, done that. I inherited an old and buggy framework in one of my tasks as a contractor.
However, I'm a very experienced, senior, developer. And since the framework was tailored for the very task it was meant, it wasn't big enough to be beyond be. It took me 1 or 2 days to understand the framework, then I gone for fixing it. Since the previous developers were a very professionals ones themselves, the documentation was good. Not perfect, but good enough to help me on the task. I had even time to do some refactoring, in order to eliminate a external dependency from a old (third party) framework that was not used anymore.
But don't take this history as the common ground. Good documentation is not something easily found. God knows it's not always I can convince the client that he should allow me to "waste time" writing good documentation.
In the end, you're right, there is no clearly defined criteria for which approach is better than the other, both ways has a very good chance to bite you in the ass. My perspective however, not as a developers of production systems but a software testing engineer (writing code to break other people's code ;)), what I see is bugs, bugs everywhere.
Hey, I did that too!. Long before I gone Senior on software development, I was a black box tester. While being trained to white box testing, I got a chance to do development and jumped on it.
I cut my teeth on the Rational Suites (it was just before IBM's acquisition). The Rational's Test RealTime was something very impressive at that time! (I hated ClearCase/ClearQuest).
As a side effect, I always tried to be in good terms with the testing team. In the very, very few times I had to say "no" to them, I've heard.
Hardly any new feature, however straight forward it appears in its original specs, that's not can of worms of new and exciting issues. That's why I'm very skeptical of using new code when existing, already tested code exists.
Now I understand better your point of view. You're used to environments with long lifespan. You can test the software now, and be sure it will work next year because you know that the environment will not change unless you (or someone you thrust) approve the change.
Not many companies can afford such control, and some product niches just don't allow it (I was a embedded developer for the automotive once).
As I said befo
If you're a dinosaur, yes! :-)
That meteorite was only 15 to 17 meters long.
The size of its blast was due to its tremendous energy (a.k.a. speed) when it penetrates our atmosphere....
Reference.
This is hard to prove or disprove.
As everything else in this business. =P
For example, I'm tired of catching [insert your favorite MacBook manufacturer =P here]'s mistakes on their protocols implementations. Why? Because they simply refuse to acknowledge their existence!
Since I already implemented a Bluetooth Protocol for a embedded system, I KNOW how to debug and catch this quirks, but who am I to dare to say Apple is wrong?
"The implementation is not wrong, it's just not right." - yeah, they shoved it on me.
This line of thinking is the rule on this industry. No one is accountable for anything, and if you have money enough, you can say anything that it will stick.
Sure, throwing some huge framework on a small problem is not a sensible approach. Seems like a no-brainer. But where to draw the line? A real life application constantly grows, and has a good chance to eventually use a growing percentage of the features exposed by a given framework.
That's the point! THERE IS NO LINE!.
The decision is made, mainly, by environmental and political questions (and not technical!). How much time do you have to deliver the first prototype? How much years the system is expected to be used? The running environment is expected to change in the near future? How much money the client is willing to shove on the project (seniors developers are not cheap!)? Do you thrust the client will not change his mind in the middle of the project?
If you know your application will not outgrow its initial specs (in an unexpected way), it might make sense to opt for an own framework.
And how you know that your application will outgrow in a expected way, so you can be confident that your framework of choice (at the moment!) will be the right one in the years to come?
This is a catch-22 situation. Since you don't know where in hell your system will end up computing bugs =P, you don't now neither if the framework you're using will not bite you in the arse.
So, you will be bit in the arse no matter what, using a custom framework or a "standardized" one from third parties.
Make the choice that makes sense at the moment. You can't save the future, make the best you can do in the present.
My personal experience, however, is that developers too often opt for their own solutions, maybe due some kind of not invented here syndrome, and duplicate a lot of work.
My personal experiente says you're getting it so wrong. (Experienced) developers like their own solutions because, by worst they're, they will solve exactly the problem they have under their eyes without having to learn a lot of "possible solutions already made" that almost solve such problem (making him patching the problem to fit the solution).
More times that I would find reasonable I spend more time surviving the framework then using it. Sometimes it worths the pain (you're right too), but on a lot more, it does not.
And since I'm paid for the problems that I solve NOW, and not by the problems that I will not provoke TOMORROW, it's easy to understand why good and experienced developers tends to "reinvent the wheel". It's better for us to have a so-so wheel that fits perfectly our wagon, than a perfect one that makes me change its fscking chassis (for the same price!).
That is bad in a lot of ways,
Please don't be part of the problem you complained in your first paragraph. Don't use subjective arguing. ;-)
as a well maintained framework with multiple developers and documented bugs is always preferable to completely new code.
Using a giant framework, built and maintained by people that you don't know neither can rely on. and that you don't understand how to fix can cause a lot more of trouble than you think. Can I mention phpnuke? ;-)
Sometim
Usually, frameworks are not written and maintained by one person. And thus, you are free to worry about your own code and its bugs, and have others worry about the framework's bugs (within reason, for crucial bugs you will of course need to worry about finding a viable workaround). Code reuse is a good thing, and no single person is smarter than > 1 person.
Also, frameworks do not usually change completely in less than a year, and the change that does happen is gradual - as long as you keep the framework you use up to date the learning curve is flat.
Yeah. Wordpress is the most secure platform to develop on, right?
The bigger the framework, more useless (for your current application) code on it. Code that can have bugs itself, and since you didn't wrote the code, you're just screwed up unless fix it yourself (what you probably would do faster if you were using your own).
If frameworks would usually change in less than a year, we would probably had less problems. But you're right, frameworks don't change in less than a year. Browsers, Operating Systems, Computer et all, all of them do. A Service Pack, a Browser update, a little permission change on some obscure file, and you can't guarantee your code will run fine anymore.
And you alone just can't test that huge framework on every change that happens. You must thrust God that everything will be alright.
Risky Business. God is not a Software Engineer.
Jokes aside, please read carefully what I said before: There's something very wrong when you spend less time building your own framework than learning a well known and stablished one to do your task.
Even Wordpress has a lot of very good uses. But I would not use this beast for my personal tech blog, God Damnit. Why should I expose my entire site to the Wordpress exploits just because a personal blog? Spend some hours writing that static HTML pages and it's done! Learn to use CSS correctly (what you need to know anyway) and you will not have problems when you decide to change your theme.
Frameworks is not inherently evil. But using a huge one just for the sake of using it is dumbness.
When you do real programming, do you implement your own printf()?
Because they needed to fit an operating system in 14KB.
Yes. When I wrote a Operating System tool (for a embedded application using Freescale's FlexOS), I did. Since I didn't needed a full blown printf implementation, I was able to save some precious kbytes, invaluable resource to be spent on code that make the user happier.
Look, pal. Read carefully what I said before; "When you spend less time writing your own framework than trying to use an already stablished one".
In absolutely no moment I even implied that every framework is evil.
Frameworks to do simple things may be stupid, but it's just as stupid to write your own code every time too.
Being that the reason that old school programmers make their own frameworks? :-)
There's something very wrong when you spend less time building your own framework than learning a well known and stablished one to do your task.
You can argue that a well known and stablished framework will save time on the long run. But I will counter-argue stating that this is only true if the guy knows the framework by heart - otherwise he will be screwed up on every single mistake did by someone's else.
It's better to "waste" a little time now and in every project in the future, than to waste a huge one now and then in the hope that somewhere the future I will be able to throw up a new system every week without hassle - what's is not going to happen anyway, because in less than a year everything is changed, and things will start to break, and the cycle starts again.
More likely a margin call. If he borrowed against his sinking stock portfolio, at some point he would be forced to liquidate it to satisfy the terms of the loan.
Makes sense!
So if this is intended to sink the stock it looks like it failed.
Or the Takeover already started.
On a automatic car? With electronic traction control? Risk business.
If the wheels got locked at that speed, you are dead.
Or you know that someone with deep pockets paid him to do so, lowering the prices and rendering the company vulnerable to a Hostile Takeover.
Do you know Siemens VDO, I mean, Continental A/G, I mean, Schaeffler Group? :-)
The programmer does what the boss tell him to do.
The Progress Bar loses his functionality when Windows 96 start to use it just as something that moves on the screen. No real processing is associated with the Bar or Animation activity!
On the other hand, there are programs that do it right! Unfortunately, one of the best examples I have is a console Linux program: The Midnight Commander - so, very few people nowadays is exposed to a correctly written Progress Status notifier mechanism...
What are we; but slaves to finances?
I think you're holding, I mean, taking it wrong.
We aren't slaves to finances. We're slaves to another people, that happened to control this weird thing called finances.
Do not confuse the tool with the hand that wields it!