There is no shortage of software products many of us use online that are rooted in university CS projects. Instead of a generic call to arms, perhaps this CS professor could do something about it. He has the means and the resources at his disposal, after all.
You'll have to disassemble a UPS -- take the battery out of your UPS, and run lead wires from your battery to the corresponding positive and negative leads in your UPS. Voila.
Apple killed the floppy? They killed a technology by omitting it from a product whose market share couldn't even be measured in single-digit percentages? I know Steve Jobs is amazing and all, but that's just super human.
Apple merely recognized the obsolescence of the floppy disk, and omitted it because it was overhead that provided little value. Netflix is recognizing that streaming is the future of their business, and is acting to make that future as lucrative as possible.
The article assumes these companies are causing trends, when they are merely reacting to them.
Regulations have a declared intent of stopping assholes. They are designed to expand the government's reach and tilt the playing field in favor of the big fish.
At that scale, though, Netflix probably negotiated a pretty sweet deal with Amazon. A flagship customer like Netflix really overcomes a lot of the objections customers may have. It's a pretty powerful answer to any company who questions whether or not Amazon can operate on an enterprise scale. Odds are, Amazon is sacrificing its profit margins, possibly even eating a loss, to host Netflix's operations.
IANAL, but I have been involved with my share of patent law, both in defending against patent infringement and in applying for patents. Your assertions suggest the only exposure you've had to the patent process comes from reading Slashdot headlines. There is no rubber stamp at the USPTO. An examiner spends months to years on a single application, researching prior art, questioning the inventor(s), and judging the novelty of the invention. Many times, an application will go through a rejection/revision cycle several (up to 3, I think) times before the examiner's objections are fully overcome. And even then, the application is usually rejected.
Patent litigation is also fairly rare (albeit expensive). Most defenses against patent infringement are centered around trying to invalidate the patent altogether. This means the patent holder is typically faced with losing his intellectual property rights altogether. It's uncanny how suffering real, irreparable damages if you lose a suit you bring up against someone else can shape your strategy.
Well that... and the law. First-to-file vs. first-to-invent and the prior art obstacle to getting a patent awarded are two wholly different segments of patent law.
Then it all just depends on the incentive you give to provide quality. If the CEO of a security provider is held criminally-liable (and I mean PMITA prison) for any security breaches that occur on his/her watch, you can bet that company will have proper incentive to ensure security.
Markets break down when the consequence of failure for the participants is not dire.
.NET code from 11 years ago will also still work just fine, too. VB code still runs as fine as it ever did with the final version of the VB runtime. Even if Windows 8 "abandons" Silverlight, there will almost certainly be nothing to stop someone from building and running a Silverlight application, much like nothing but common sense would stop someone from building and running a VB6 application. To this day, you can still download the latest service packs for Visual Basic 6.0 from Microsoft's site. This is not abandonment. Every product, either proprietary or open source, will reach an effective end of life, where no new features are implemented. The last C++ standard was released 8 years ago. Are there "legions" of C++ users who claim to be left in the lurch? No.
The aforementioned technologies are careful to maintain backwards compatibility when they are updated. But you can't expect full compatibility between one platform and another, just because both are produced by the same company.
You're not exactly correct, there. Through XP, Windows installs will suffer performance degradation over time. Microsoft committed down a particular path to maintain backwards compatibility with software built on older versions of the OS, and that has come with a price. The Win API is so rife with hacks to achieve this goal, that all kinds of bizarre breadcrumb files and file fragments are left behind, never to be cleaned up.
This does not mean I am an endorser of a scammy registry cleaner application. These are just the facts of legacy elements of the OS.
I hate the claim that people "can't afford nutritious food." That is a load of bunk. People are too lazy to buy raw ingredients. Steaks and roasts are expensive. Boneless, skinless chicken breast is expensive. Bread is expensive. Things that are less expensive:
1. Whole chickens 2. Cuts of meat that you can butcher yourself. 3. Flour, salt, and yeast.
The problem is, few know how to be frugal anymore, because it has been so long since we as a society have had to do without things that our notion of "poor" would make earlier generations fall on the floor laughing. Tell someone that you butcher your own meat, cut up a whole fryer and save the bones for stock, make your own bread, etc., and that person will look at you like you just grew a second head.
Really? Because I just priced out service on O2 with 300 minutes, 1GB data, 250 text messages, and 50 MMS messages, and I'm at £44.11. At today's exchange rates, that's roughly $73. However, what we don't have is a 20% VAT (TOTAL taxes and fees charged by the US are about 10-12%); also, we do not pay MTRs here. In monthly service alone, I'd be paying about 12% more with O2 than I am with AT&T, and I would end up with fewer minutes, half the data, and be charged money on top of that for calling phones on other networks. So I'm not seeing where we're soooo expensive.
If only AT&T had had the foresight to charge money for their data plans. Then they'd have had additional revenue streams from all the new subscribers these devices brought to them. Hindsight is 20/20, I guess.
The only technical knowledge a product manager should need is in that of the problem domain of the product. The question is simple... "what do you want this to do, and what is the business value of it?"
If the business cannot accurately portray the answer to that question, and/or the team cannot or will not understand the message it is getting from the business, then a problem has been uncovered. It should be solved (and it can be), not wallpapered over.
Releasing code in short cycles is not a license to produce trash. An effective Agile team needs to be committed to the ideal of shipping bug-free software, and also provide itself the means to achieve that ideal. Is everything going to be perfect, at any point in time? No. But that does not mean we should not strive for it.
Agile often gets a bad rap because there are so many teams that practice Agile-in-name-only. At a firm where I once worked, I had a CIO claim that Agile was "nothing more than a bunch of short-term waterfalls." That is a perfect mindset to get to the end which you describe. There is a great benefit to seeing tangible results in short iterations -- it allows for rapid priority shifts in a business, and mitigates the obsolescence of particular business requirements. Plus, it is always time better spent to solve today's problems today, and defer tomorrow's problems. However, you cannot reap those benefits in a sustainable manner without a paying certain costs. Namely:
1. Diligent tests in code, and good continuous integration are an absolute must. What allows you to defer problems that are not important right now to the future is having a reliable method ensuring that you unearth issues as soon as they arise by building frequently and having a full suite of tests that can reliably tell you when a bug has been introduced. This provides the entire organization the confidence that significant architectural changes can be done in a short cycle. It also provides for better design up front -- being able to effectively test a module of code in isolation dampens the ability of that module to introduce breaking changes in other parts of the system. 2. Someone from the business with a real stake in the work product absolutely has to be involved in the process. Without an interested stakeholder, an Agile project will fail brilliantly. This person must make him- or herself available to the team throughout the project, to provide feedback, answer questions, etc. Being able to give feedback and have it actually integrated is one of the primary benefits to the business, so if a stakeholder can't be bothered to be available, the project is a worthless venture. 3. The team must be motivated to produce high quantities of high quality work. True Agile teams break down hierarchy. There should be no perceptible "reward/punishment" system. If you do not have a team whom you cannot trust without the threat of being fired, your project will fail.
Nothing is a magic pill. I've comfortably worked in both Waterfall and Agile environments. But all things being equal, I've come to prefer the latter. It just feels like a more natural way to work, and honestly any workarounds we've come up with in the past to evade the tax of heavy process have greatly resembled Agile development.
And this is a prime example of why. With a financial incentive to write tickets, that will take precedence over what the intent of traffic laws -- to manage public safety.
The problem with speed cameras and red light cameras is that the revenue generated from them (at least in an area where most of the travelers are local, regular commuters) is a short-term bump. As people are fined for their actions, they adjust their behavior accordingly. Unfortunately, even though law enforcement is intended to alter people's behavior to NOT break laws, municipalities base their budgets on the bet that people will continue speeding or running red lights regardless of enforcement.
This is where the problem comes in. When the inevitable shortfall in revenue arises, they begin to look for other areas to exploit. As people alter their behavior, more behaviors will be criminalized. At least a half-dozen cities have been busted for altering their yellow light times. Why? To make more people guilty of running red lights, so they can boost the money they make from the fines.
So it would not surprise me if these cameras were inaccurate, if not rigged to deliver false results. Desperate times beget desperate measures.
To which I would suggest that OCCAM is being disingenuous, if not downright dishonest.
It is crucial to be able to assign a date and time to the offense. No case would be worth its salt if it couldn't prove the vehicle was at the place and time of the offense. There also needs to be some kind of link between the speed measurement and the vehicle being measured. Again, accurate time indexes are crucial.
Without that, you could just spit out photos of a sample of cars, and apply random speeds to them, the thinking being that most people think/know they're speeding at any given time, and would not bother to fight the ticket.
To have an *average* velocity of 15 mph less than that at which he was clocked, he'd have to have decelerated by quite a bit more than that. This also means the driver would have to have known the exact moment when the photo was taken, and had the response time necessary to jam on the brake pedal to reduce his speed by enough to get to an average of 35 mph over that 50 feet.
I'm really not in the mood to do the math here, but it seems pretty likely that the cars' average velocities were at or close to what is calculated with the known distances and times (assuming those are measured accurately, of course.
In large quantities, the per-unit cost of end-to-end delivery (from manufacture to store) is pretty negligible anymore. It's only an educated guess, but the total costs borne by all parties is most likely under $5, and may even be $1 or less.
Manufacturing costs practically nothing per unit these days. Think about it -- you and I can buy writable DVDs at retail for 20-30 cents apiece in small quantities. What do you think a manufacturer pays for them? So you're talking pennies per item to make it. Shipping has become so consolidated anymore that that is also a minimal marginal cost -- there's not a truck that is just full of Super Shootemup 2 packages. Rather, there is a truck that is full of many games from many providers. And the manufacturer only needs to get it as far as the retailers' distribution centers, at which point the retailer picks up the tab. And those costs are marginalized as well. Again, it's not like Best Buy's truck is only carrying a few copies of the game and nothing else. The small number of people involved adds maybe a few more pennies per unit. Aside from opportunity cost, such as "Best Buy can't ship these DVDs to its store because there are too many of these $60 games on the truck," unit cost is probably a lesser factor when considering profit margin.
The issue is they want to maintain the high gross margins they enjoy. But reality is dictating something different.
I'll still buy a handful of $50-60 games. I'm a huge college football fan, so whenever NCAA 20** comes out, I buy it the day of release. The camaraderie with other fans in the first few months of the game's release does add some intrinsic value to the product, even if it is a copy-and-paste from the previous year most times.
With me, it's about the individual game. I'll pay the early adopter premium on a sports game, because time and age are factors in the value I derive from it. However, when it comes to yet another shooter or action game, that is a ripoff or sequel, I'll just wait it out until it hits the discount phase.
Game makers could be as intolerant and draconian as they wanted if their games were better. And there's the rub. Creativity has been usurped by the quest for margins. Take a popular game, add new backgrounds while keeping all the objectives, levels, missions, or whatever following the exact same script, and call it a sequel. Games are being released with hardly a line of new code being written. They want to sell Wal-Mart clothes at Barney's prices.
This is just proof that capitalism works. If you intentionally devalue your own product, yet still demand a premium price, you're not going to sell anything. You can't set prices in a market. Well... unless you hold a monopoly over a true necessity, and a game producer fulfills neither.
It's quite simple. Start making $60 games again, and you will be able to sell $60 games.
Particularly in IT, every situation is unique. Changing jobs can enable you to broaden your knowledge and skills, but it can also mean a bunch of lateral moves. Promotion can show a progression in your career, but that can often lead to dead end middle management paper pushing. It really depends on what you're looking to do, and what the climate is like in your current situation. I hate to speak in such useless platitudes, but you really have to look at your own fulfillment, and decide for yourself whether you can find opportunity to achieve it in your current company, or if you should look elsewhere.
I think it's more a divergence than a decline. Twitter got a bump across the board, but local and small-reach presences don't seem to be sustaining. There appears to be more interaction among users with talk shows, columnists, and big name brands, not less. It's great for broadcasting, and for collecting short bits of feedback.
Some companies jumped all in on Twitter, but really got no value. Others have made Twitter a priority for several purposes -- communicating deals, general marketing, and collecting customer feedback. In fact, Best Buy and Comcast have gone as far as to make Twitter a major focal point in their customer service offerings.
While Twitter may be receding in importance for your company, that does not mean it is receding in general.
Slashdot Mirror
There is no shortage of software products many of us use online that are rooted in university CS projects. Instead of a generic call to arms, perhaps this CS professor could do something about it. He has the means and the resources at his disposal, after all.
You'll have to disassemble a UPS -- take the battery out of your UPS, and run lead wires from your battery to the corresponding positive and negative leads in your UPS. Voila.
When the choice is between inefficiently-supplied electricity, or no electricity, which are you going to choose?
Apple killed the floppy? They killed a technology by omitting it from a product whose market share couldn't even be measured in single-digit percentages? I know Steve Jobs is amazing and all, but that's just super human.
Apple merely recognized the obsolescence of the floppy disk, and omitted it because it was overhead that provided little value. Netflix is recognizing that streaming is the future of their business, and is acting to make that future as lucrative as possible.
The article assumes these companies are causing trends, when they are merely reacting to them.
Regulations have a declared intent of stopping assholes. They are designed to expand the government's reach and tilt the playing field in favor of the big fish.
At that scale, though, Netflix probably negotiated a pretty sweet deal with Amazon. A flagship customer like Netflix really overcomes a lot of the objections customers may have. It's a pretty powerful answer to any company who questions whether or not Amazon can operate on an enterprise scale. Odds are, Amazon is sacrificing its profit margins, possibly even eating a loss, to host Netflix's operations.
IANAL, but I have been involved with my share of patent law, both in defending against patent infringement and in applying for patents. Your assertions suggest the only exposure you've had to the patent process comes from reading Slashdot headlines. There is no rubber stamp at the USPTO. An examiner spends months to years on a single application, researching prior art, questioning the inventor(s), and judging the novelty of the invention. Many times, an application will go through a rejection/revision cycle several (up to 3, I think) times before the examiner's objections are fully overcome. And even then, the application is usually rejected.
Patent litigation is also fairly rare (albeit expensive). Most defenses against patent infringement are centered around trying to invalidate the patent altogether. This means the patent holder is typically faced with losing his intellectual property rights altogether. It's uncanny how suffering real, irreparable damages if you lose a suit you bring up against someone else can shape your strategy.
Well that... and the law. First-to-file vs. first-to-invent and the prior art obstacle to getting a patent awarded are two wholly different segments of patent law.
Then it all just depends on the incentive you give to provide quality. If the CEO of a security provider is held criminally-liable (and I mean PMITA prison) for any security breaches that occur on his/her watch, you can bet that company will have proper incentive to ensure security.
Markets break down when the consequence of failure for the participants is not dire.
.NET code from 11 years ago will also still work just fine, too. VB code still runs as fine as it ever did with the final version of the VB runtime. Even if Windows 8 "abandons" Silverlight, there will almost certainly be nothing to stop someone from building and running a Silverlight application, much like nothing but common sense would stop someone from building and running a VB6 application. To this day, you can still download the latest service packs for Visual Basic 6.0 from Microsoft's site. This is not abandonment. Every product, either proprietary or open source, will reach an effective end of life, where no new features are implemented. The last C++ standard was released 8 years ago. Are there "legions" of C++ users who claim to be left in the lurch? No.
The aforementioned technologies are careful to maintain backwards compatibility when they are updated. But you can't expect full compatibility between one platform and another, just because both are produced by the same company.
Well, it's news to at least one person. Otherwise you wouldn't have had a post to which to reply.
You're not exactly correct, there. Through XP, Windows installs will suffer performance degradation over time. Microsoft committed down a particular path to maintain backwards compatibility with software built on older versions of the OS, and that has come with a price. The Win API is so rife with hacks to achieve this goal, that all kinds of bizarre breadcrumb files and file fragments are left behind, never to be cleaned up.
This does not mean I am an endorser of a scammy registry cleaner application. These are just the facts of legacy elements of the OS.
I hate the claim that people "can't afford nutritious food." That is a load of bunk. People are too lazy to buy raw ingredients. Steaks and roasts are expensive. Boneless, skinless chicken breast is expensive. Bread is expensive. Things that are less expensive:
1. Whole chickens
2. Cuts of meat that you can butcher yourself.
3. Flour, salt, and yeast.
The problem is, few know how to be frugal anymore, because it has been so long since we as a society have had to do without things that our notion of "poor" would make earlier generations fall on the floor laughing. Tell someone that you butcher your own meat, cut up a whole fryer and save the bones for stock, make your own bread, etc., and that person will look at you like you just grew a second head.
(agree with you on most everything else though)
Really? Because I just priced out service on O2 with 300 minutes, 1GB data, 250 text messages, and 50 MMS messages, and I'm at £44.11. At today's exchange rates, that's roughly $73. However, what we don't have is a 20% VAT (TOTAL taxes and fees charged by the US are about 10-12%); also, we do not pay MTRs here. In monthly service alone, I'd be paying about 12% more with O2 than I am with AT&T, and I would end up with fewer minutes, half the data, and be charged money on top of that for calling phones on other networks. So I'm not seeing where we're soooo expensive.
If only AT&T had had the foresight to charge money for their data plans. Then they'd have had additional revenue streams from all the new subscribers these devices brought to them. Hindsight is 20/20, I guess.
The only technical knowledge a product manager should need is in that of the problem domain of the product. The question is simple... "what do you want this to do, and what is the business value of it?"
If the business cannot accurately portray the answer to that question, and/or the team cannot or will not understand the message it is getting from the business, then a problem has been uncovered. It should be solved (and it can be), not wallpapered over.
In a word... no.
Releasing code in short cycles is not a license to produce trash. An effective Agile team needs to be committed to the ideal of shipping bug-free software, and also provide itself the means to achieve that ideal. Is everything going to be perfect, at any point in time? No. But that does not mean we should not strive for it.
Agile often gets a bad rap because there are so many teams that practice Agile-in-name-only. At a firm where I once worked, I had a CIO claim that Agile was "nothing more than a bunch of short-term waterfalls." That is a perfect mindset to get to the end which you describe. There is a great benefit to seeing tangible results in short iterations -- it allows for rapid priority shifts in a business, and mitigates the obsolescence of particular business requirements. Plus, it is always time better spent to solve today's problems today, and defer tomorrow's problems. However, you cannot reap those benefits in a sustainable manner without a paying certain costs. Namely:
1. Diligent tests in code, and good continuous integration are an absolute must. What allows you to defer problems that are not important right now to the future is having a reliable method ensuring that you unearth issues as soon as they arise by building frequently and having a full suite of tests that can reliably tell you when a bug has been introduced. This provides the entire organization the confidence that significant architectural changes can be done in a short cycle. It also provides for better design up front -- being able to effectively test a module of code in isolation dampens the ability of that module to introduce breaking changes in other parts of the system.
2. Someone from the business with a real stake in the work product absolutely has to be involved in the process. Without an interested stakeholder, an Agile project will fail brilliantly. This person must make him- or herself available to the team throughout the project, to provide feedback, answer questions, etc. Being able to give feedback and have it actually integrated is one of the primary benefits to the business, so if a stakeholder can't be bothered to be available, the project is a worthless venture.
3. The team must be motivated to produce high quantities of high quality work. True Agile teams break down hierarchy. There should be no perceptible "reward/punishment" system. If you do not have a team whom you cannot trust without the threat of being fired, your project will fail.
Nothing is a magic pill. I've comfortably worked in both Waterfall and Agile environments. But all things being equal, I've come to prefer the latter. It just feels like a more natural way to work, and honestly any workarounds we've come up with in the past to evade the tax of heavy process have greatly resembled Agile development.
And this is a prime example of why. With a financial incentive to write tickets, that will take precedence over what the intent of traffic laws -- to manage public safety.
The problem with speed cameras and red light cameras is that the revenue generated from them (at least in an area where most of the travelers are local, regular commuters) is a short-term bump. As people are fined for their actions, they adjust their behavior accordingly. Unfortunately, even though law enforcement is intended to alter people's behavior to NOT break laws, municipalities base their budgets on the bet that people will continue speeding or running red lights regardless of enforcement.
This is where the problem comes in. When the inevitable shortfall in revenue arises, they begin to look for other areas to exploit. As people alter their behavior, more behaviors will be criminalized. At least a half-dozen cities have been busted for altering their yellow light times. Why? To make more people guilty of running red lights, so they can boost the money they make from the fines.
So it would not surprise me if these cameras were inaccurate, if not rigged to deliver false results. Desperate times beget desperate measures.
To which I would suggest that OCCAM is being disingenuous, if not downright dishonest.
It is crucial to be able to assign a date and time to the offense. No case would be worth its salt if it couldn't prove the vehicle was at the place and time of the offense. There also needs to be some kind of link between the speed measurement and the vehicle being measured. Again, accurate time indexes are crucial.
Without that, you could just spit out photos of a sample of cars, and apply random speeds to them, the thinking being that most people think/know they're speeding at any given time, and would not bother to fight the ticket.
To have an *average* velocity of 15 mph less than that at which he was clocked, he'd have to have decelerated by quite a bit more than that. This also means the driver would have to have known the exact moment when the photo was taken, and had the response time necessary to jam on the brake pedal to reduce his speed by enough to get to an average of 35 mph over that 50 feet.
I'm really not in the mood to do the math here, but it seems pretty likely that the cars' average velocities were at or close to what is calculated with the known distances and times (assuming those are measured accurately, of course.
In large quantities, the per-unit cost of end-to-end delivery (from manufacture to store) is pretty negligible anymore. It's only an educated guess, but the total costs borne by all parties is most likely under $5, and may even be $1 or less.
Manufacturing costs practically nothing per unit these days. Think about it -- you and I can buy writable DVDs at retail for 20-30 cents apiece in small quantities. What do you think a manufacturer pays for them? So you're talking pennies per item to make it. Shipping has become so consolidated anymore that that is also a minimal marginal cost -- there's not a truck that is just full of Super Shootemup 2 packages. Rather, there is a truck that is full of many games from many providers. And the manufacturer only needs to get it as far as the retailers' distribution centers, at which point the retailer picks up the tab. And those costs are marginalized as well. Again, it's not like Best Buy's truck is only carrying a few copies of the game and nothing else. The small number of people involved adds maybe a few more pennies per unit. Aside from opportunity cost, such as "Best Buy can't ship these DVDs to its store because there are too many of these $60 games on the truck," unit cost is probably a lesser factor when considering profit margin.
The issue is they want to maintain the high gross margins they enjoy. But reality is dictating something different.
I'll still buy a handful of $50-60 games. I'm a huge college football fan, so whenever NCAA 20** comes out, I buy it the day of release. The camaraderie with other fans in the first few months of the game's release does add some intrinsic value to the product, even if it is a copy-and-paste from the previous year most times.
With me, it's about the individual game. I'll pay the early adopter premium on a sports game, because time and age are factors in the value I derive from it. However, when it comes to yet another shooter or action game, that is a ripoff or sequel, I'll just wait it out until it hits the discount phase.
Game makers could be as intolerant and draconian as they wanted if their games were better. And there's the rub. Creativity has been usurped by the quest for margins. Take a popular game, add new backgrounds while keeping all the objectives, levels, missions, or whatever following the exact same script, and call it a sequel. Games are being released with hardly a line of new code being written. They want to sell Wal-Mart clothes at Barney's prices.
This is just proof that capitalism works. If you intentionally devalue your own product, yet still demand a premium price, you're not going to sell anything. You can't set prices in a market. Well... unless you hold a monopoly over a true necessity, and a game producer fulfills neither.
It's quite simple. Start making $60 games again, and you will be able to sell $60 games.
Particularly in IT, every situation is unique. Changing jobs can enable you to broaden your knowledge and skills, but it can also mean a bunch of lateral moves. Promotion can show a progression in your career, but that can often lead to dead end middle management paper pushing. It really depends on what you're looking to do, and what the climate is like in your current situation. I hate to speak in such useless platitudes, but you really have to look at your own fulfillment, and decide for yourself whether you can find opportunity to achieve it in your current company, or if you should look elsewhere.
I think it's more a divergence than a decline. Twitter got a bump across the board, but local and small-reach presences don't seem to be sustaining. There appears to be more interaction among users with talk shows, columnists, and big name brands, not less. It's great for broadcasting, and for collecting short bits of feedback.
Some companies jumped all in on Twitter, but really got no value. Others have made Twitter a priority for several purposes -- communicating deals, general marketing, and collecting customer feedback. In fact, Best Buy and Comcast have gone as far as to make Twitter a major focal point in their customer service offerings.
While Twitter may be receding in importance for your company, that does not mean it is receding in general.