CEO salaries are getting ludicrous, and while his $1M is not that outrageous compared to others, it still could be translated into about 10 FTEs. Setting a minimum wage for his staff, and making sure they can all survive on what they make at their job, will translate in staff dedication that will be hard to put a price on.
I think he's also thrown the gauntlet down to other CEOs, saying: "Dare you to join me!"
BoA has a really cool two-factor device. They put an RSA key generator in a credit card-sized device. I got mine for $10, it works great, and it's in my wallet with me all the time. They also offer text message two-factor, which I use as a backup to the RSA card.
AWS has been around long enough this shouldn't be an issue. If a given architecture cannot survive downtime from a server, or an availability zone, then the risk is no different than if the servers were in a locally-managed datacenter.
In short, if you don't take advantage of what the cloud has to offer in terms of redundancy, then don't expect zero downtime.
Let's face it: as far as we know, the door lock manufacturers also have a master key to all our houses. The schematics and design of the lock are not publicly available, and most people lack the skills to know if the schematics they are looking at are secure or not. It's the same with an OS. And while I *could* take the lock apart and figure out how it works, I still wouldn't know if my particular lock were secure or not, because I have not seen enough locks to know if this particular one is good or not.
Anytime this condition arises, we replace our own lack of knowledge with a trust in experts. We have to defer the judgement of security worthiness to an expert we trust, in which case we are again disinter-mediated from knowing if the lock is actually secure or not. We all trust *someone* with very specific knowledge to help us make decisions, whether that be medical, scientific, security or otherwise, and in each of those cases, we can find examples of where the expert has let us down.
As systems become more inter-connected and more dependent on standard components, they also become more difficult to diagnose. Problems in one seemingly benign part of the system can affect it and render it unusable, and now those parts may be spread around virtual datacenters and servers. We need OS guru's now more than ever, but it's also expected that those guru's know many different technologies (hence, DevOps and other automation-oriented skills). It's the corollary to what's happening in development: one developer can build more software faster than ever before, but they must also be knowledgeable in a wider range of technologies.
OP mentions a few of the factors that help achieve better software (very good, motivated developers; orientation towards quality, etc). But the most important one was left out: customers willing to pay what it costs to get quality software, and their ability to spot high quality software up-front (during sales cycle). Until that happens, the quality will continue to be poor, because as OP notes, the cost will increase (driving customers away from higher-quality) and the lack of visibility to higher quality will keep them from getting it (ie, ability to recognize a better quality product during sales cycle and pay the extra price knowing they'll actually get higher quality out of it).
Yeah right dude, Steve Jobbs certainly knows nothing about marketing.
Let's face it, the best tech companies out there are run by tech guys.
Bob Lutz is dead-on. Several companies I've worked for were run by the sales guys, and they ran the businesses into the ground by focusing on short-term profits and allowing their products to languish and eventually become irrelevant. They failed to see that investing in good technology and having a vision would ultimately give you an even larger market share. Just like Apple and John Sculley. Sure he got the company back on solid ground, but he couldn't maintain it because he wasn't a visionary tech guy. When they brought Jobbs back again, we all got iPods, iPhones, Macbook Airs and iPads. The PC world has been transformed, and Apple's market cap exceeds Microsoft's.
But the software only has to be 'good enough' for people to buy it, so there's no ammunition for developers to use to get a better schedule.
I've reflected on this problem quite a bit, and I can't seem to get past "Customers are getting what they are demanding," which is to say "not much."
None of the contracts or RFP's I see are demanding performance measures, quality measures, detailed functional requirements, etc. Nor do I see customers diving into the product and really trying it out before they buy, or comparing the competing products hands-on. Our customers purchase based on limited demos run by the vendors themselves, and those making the purchasing decisions don't have enough experience to thoroughly evaluate a product, nor do they seek the expertise of those who can. In the end, purchase decisions are made with very weak product knowledge, and create contracts that are weak on details (but strong on delivery dates).
This results in frustration all around. Vendors have to deliver what the customer wants, but can't figure out what they want until after they buy it, try it, and then complain it doesn't work they way they want. Customers unwittingly purchase vaporware from vendors. The development teams are asked to deliver functionality with little or no guidelines. Target dates for delivery are off by months. In my opinion, this occurs simply because the customer wasn't clear on what they wanted, didn't make those demands clear in their contract, and didn't make a knowledgeable purchase decision.
Which leads to no time for testing, compressed timelines, no ammunition to do it right, no clear budget or tracking of the costs, and on and on.
I learned to program in BASIC, on an Apple ][+, back in the early 80's when I was 10 or 11. I loved it, but I started wondering how programs like word processors could access a large document in RAM, and work with files bigger than available memory, and other mysteries...which led me to learn C (with a classic Borland C compiler) at 15, and eventually to a CS degree.
In my case, BASIC (and I did LOGO too) didn't ruin me, it made me more curious and moved me into the more complex languages. When I got to college, data structures class was a piece of cake, as I'd already done linked lists and other structures while learning C, and I could easily deal with pointers and pointer arithmetic, multiple indirection, function pointers, and more. I feel a debt of gratitude to the humble BASIC language.
Just a couple weeks ago, I started teaching my son Apple BASIC from a web-based Apple BASIC emulator, hoping that he'll be as excited about programming as I was.
I second this! This is exactly what's keeping most businesses I talk to from using it. Because of the lack of standards, your implementation either isn't compatible with everyone, or if it is you provide a bunch of really complex options that only PhD's understand.
This also produces fear...IT management doesn't understand all those options and the implications of one over the other, and don't want to be held accountable for encryption that doesn't work.
Until there is a simple, uniform and free way to implement certificate authentication, it's just going to wallow.
This is what they were saying 2 years ago, that the megapixel wars were over, that the sweet spot was 8MP. HAH.
Remember when 22MP was what you bought in a $30,000 digital back camera? At the same time, the Canon 1D line was 10MP or so. Um, yeah that was only 5 years ago.
I say no, the megapixel wars are definitely NOT over yet.
The other thing mentioned here is a concentration on quality. That's been happening hand-in-hand with the megapixel wars. So the latest in the Digic line of processors can both handle more pixels, faster, and produce better quality images at higher ISO, all at the same time. I would expect that to continue as well.
True, at some point physics will take over, as it was supposed to YEARS ago in the microprocessor market, but now we have 45micron processes that nobody dreamed of. The same will happen for CCD's and so on. Who knows where it will end.
Ah, so it's a way to sell more machines to run more infrastructure software (also sold) which companies think will increase their scalability, which they don't really need because most of them are never going to have the amount of business that would force them to scale, where simple client-server software would suffice while they're going down the tubes.
Guess you've never been to the other side of that. The other side of that is a set of applications that are good enough to win your company the business, but that don't work together at all.
You can say "you should have thought about that in the first place, good design would have cleared that up" but good, thorough design that attempts to make everything work together flawlessly results in long development cycles and lost business.
Our company won, we built the best products and got the market share, and now we've got a set of applications that our customers expect and want to work together, and we are struggling to deliver it.
SOA is one way we can help with this problem. We can add SOA interfaces to each application, and start constructing the one integrated product our customers want, in an orderly way, quickly, without re-writing all our apps, and piecemeal. We can add SOA interfaces to each application's back end, one at a time, prove it works, and then work on meta-applications to combine the results.
We built much of the software to handle this ourselves. There are OSS options for most pieces of this architecture if we wanted to use an ESB engine (check out Mule for example), and with our VM environment we should not need significant investment in infrastructure. We just need time to build it, and hence corporate wherewithal.
SOA (and ESB and the like) in-and-of themselves will not provide a solution to enterprise integration, any more than the EAI engines of 10 years ago, but at least they provide a common technology to build around so that other developers can tap into the functionality of our applications.
The same kind of arguments were made in support of C: that hard-to-maintain spaghetti code is not the language's fault, it's the developer's. But the bottom line is this: if the language fails to enforce some basic good coding practices, then the code won't be easy to maintain. It's difficult, if not impossible, to find and hire the kind of talent across your organization that can keep the code maintainable and readable. It's just as hard to review all the code to ensure it meets your development standards, and train junior engineers on how to do it properly. Therefore, just having Perl or C code to maintain means you are almost guaranteed to have harder-to-maintain code, that has to be worked by more-senior developers. Those very developers are who you need plugged into new projects that require senior developers and out-of-the-box thinking. If they are tied up cleaning up the spaghetti that other engineers produce, you lose productivity across your organization, and your senior guys want to quit.
Java,.NET and other shiny new languages help in significant ways in making software products easier to develop and maintain. So Even though I can code nice C code, and I can handle pointer arithmetic and memory allocation well, doesn't mean I can find all the resources I need to ensure that same level of development in all my products.
iTunes is the worst, IMO. It seems no matter how many times I patch it, just days later there's another patch. Every patch is a full download and reinstall, and every patch re-installs the damn Quicktime thingy in my taskbar. And now it sends me Safari too. Ugh!
I'm with you. I like Vista just fine. I have one annoyance with it, but then I had some with XP too. My XP installation was starting to feel it's age and that's when I replaced it with Vista.
Don't get me started with Linux annoyances, which I noticed there is no book for BTW. Funny that. NAAAAAW! No annoyances with Linux or any other unix, they all work just perfectly and never ever have a problem or lack of functionality. Excuse me while I sneeze -- b*llsh!t!
Go ahead, call me fanboy or whatever, but in the end Linux still disappoints me more than Windows does. I still get more done with my Vista box than I ever did with Linux on my desktop. (Oooo, Slashdot blasphemy!)
None of these API's just fell out of the sky and landed in Microsoft's lap; they were built tediously and at great expense. And let's not forget that these are not the types of functions that are really making Microsoft top dog. Microsoft is top dog due to social and business factors, not API's and technical ones.
Funny that there are endless discussions about the poor technical quality of Microsoft's products, and at the same time rants that Microsoft is gaining an unfair advantage via technical means. Either the technology is good or it's not. If this case is valid, then we must also acknowledge that Microsoft's technology is king too.
When your installed base consists primarily of smaller groups of art-related positions within a larger organization, it's not hard to make the switch is it? The corporation's custom apps, business apps and network apps all reside firmly on Windows machines.
The Mac machines, in contrast, are small in number and largely standalone. All they have to do is replace the machine, upgrade the commercial software (largely Adobe suite and/or Quark), and you're done.
The thing that is scaring bright technologists away from the field is simple: businesses see IT developers and other technologists as nothing more than factory-line workers of our day. We are interchangeable parts, and therefore not worth as much to the company as upper management is...or middle management even.
So for our careers to grow, ironically, business pushes the brightest technologists to management, leaving an even-larger gap in capable engineers. There is nowhere else for us to grow into (case in point, I've been a Senior Engineer for my entire 10-year IT career, there's no higher technology position to go to).
In fact, development and other complex IT tasks require a type of worker that is not comparable to any other field. They are largely self-managed, and must work out engineering complexities unheard-of in other fields. The bredth of technologies and knowledge are only comparable to the most high-knowledge careers such as law, medicine, and bio-tech.
Further, the work these technologists do, and the quality of that work, directly affect the bottom-line of the technology company. The loss of a single key technologist can have a ripple-effect that is hard to quantify, but that definitely impacts the bottom line. But due to the manufacturing-centric business practices of corporations and the MBA management crowd, these dollars are never realized. Hence, management views these workers as an expense, and not generating any revenue. Conversely, sales staff, who produce nothing re-sellable on their own, and who cannot affect the cost-basis of a company much, are revered by upper-management because of the positive cash-flow realized by landing sales, and their salaries and position within the company are commensurate.
Until IT business management practices catch up to the new business landscape, they will continue to scare off the brightest talent, forcing the best technologists into management or other positions in order to see their careers continue to grow. I think Google and a few other top-tier technology companies get this, but the remainder continue to flounder in the IT landscape.
You can see this ultimately realized by "dad's advice": You don't want to be doing the work, you want to manage. Anyone can do the work.
No. Not everyone can do the work in this field, just as not everyone can be a bio-tech engineer, and until this attitude changes from business to home, IT won't attract a large crowd.
I remember it well. For my 12th Birthday, I wanted a computer. I went to the store (Montgomery Wards I think( and tried out several, and it became a bakeoff between the Sinclair and the Vic20. I chose the Vic in the end because it had a full-size keyboard. I thought the Sinclair would be difficult to type on.
Eventually I added a Commodor RGB monitor and a tape drive. I got the tape drive at Toys-r-Us (yeah, they used to sell home computers) and paid $60 for it. That was something like 1984.
Not long after I upgraded to the C64, and eventually a PC.
I have to agree. I buy almost all of my software online these days, and was SHOCKED that couldn't buy a license for WOW online. You can't buy a massivly multiplayer ONLINE game online?
My friend gave me the disks to install with, and why not? It's a subscription service to start with. The idea that I then had to pack up and go to the store and buy a copy was absurd.
Heck, I didn't even think you'd have to pay for the software, since it's an online monthly fee anyway, just roll the cost of the software into the online fee and be done with it.
In the end I did have to go to the store, just so I could have the license code off of the disk sleeve. I've never actually used my disks, or even read the box.
And think of the viral-marketing referral that went on there.
Imagine an article about your life appears on Wikipedia for millions to read, an article that will last forever and may very well shape opinions about you as a person. The author of this article in Wikipedia has never met you, and doesn't necessarily like you or what you've done with yourself. They author the article, you see errors or omissions, but aren't allowed to edit them. Worse, people who definitely don't like you try to chime in, those who definitely do like you fight back...but they're all wrong.
Okay, so that's extreme, and we're not politicians. I don't know if the articles in question were negative or misleading, but how can someone sitting at a terminal in Nashville TN, like myself, possibly know what XYZ politician is really like, what they've really done, who they really are? I don't know these people, and my only contact with them is through a decidedly limited and biased media, soundbytes and highly-edited speaches.
Of course the idea that politicians can edit their record is creepy and could lead to Orwelian misinformation, but put yourself in their shoes for a minute...it may not be all that difficult to understand.
Modern software development relies on an ever-expanding list of external factors. Case in point, our application ran perfectly fine until one day, it started crashing. The errors gave us no clue to the problem. As far as we could tell, the software was fine. Our software ran on top of a J2EE server, which runs on top of a JVM, which runs on top of an OS, which runs on top of hardware. It relies on database drivers, which connect over a network, which run against a database, which itself relies on the os, which runs on hardware. The J2EE server, of course, relies on the web server, and the driver to make the two work together. They all rely on the firewall for security, and the crypto flavor-of-the-year for HTTPS security.
All of these pieces can be culprits in the issue, but only one of those is in your direct control, that being your source code.
In the end, a MS patch against the OS caused issues in the JVM which caused issues in the J2EE server, causing our JDBC connections to lock up and fail. To find that we had to check every piece mentioned above. Swapping out to another JVM fixed the issue, but was risky because the source, which we purchased from a third party, was not qualified to run on the newer JVM.
Now imagine unwinding all of that in court. Who's fault is it? MS is just patching their OS. Sun can't be held liable for a bug in a JVM that's no longer being maintained, and was not certified to run on the newer OS patches, the J2EE server can't be upgraded because the app isn't built to run on it.
The fact of the matter is that you can't hold the engineer who designed the break pads responsible for a crash if the driver can switch out the engine, transmission, wheels, tires, diffs, etc., and can drive past the limits of the design of the automobile.
Ideas like holding software developers or development companies accountable will lead to far less software development, more expensive software, with very hard vendor-imposed limitations, like "by agreeing to this EULA you agree to run this software on a dedicated, vendor-approved machine, with the os of our choosing, and you may not patch the os or hardware drivers unless it is cleared by us."
Slashdot Mirror
CEO salaries are getting ludicrous, and while his $1M is not that outrageous compared to others, it still could be translated into about 10 FTEs. Setting a minimum wage for his staff, and making sure they can all survive on what they make at their job, will translate in staff dedication that will be hard to put a price on.
I think he's also thrown the gauntlet down to other CEOs, saying: "Dare you to join me!"
BoA has a really cool two-factor device. They put an RSA key generator in a credit card-sized device. I got mine for $10, it works great, and it's in my wallet with me all the time. They also offer text message two-factor, which I use as a backup to the RSA card.
AWS has been around long enough this shouldn't be an issue. If a given architecture cannot survive downtime from a server, or an availability zone, then the risk is no different than if the servers were in a locally-managed datacenter.
In short, if you don't take advantage of what the cloud has to offer in terms of redundancy, then don't expect zero downtime.
Let's face it: as far as we know, the door lock manufacturers also have a master key to all our houses. The schematics and design of the lock are not publicly available, and most people lack the skills to know if the schematics they are looking at are secure or not. It's the same with an OS. And while I *could* take the lock apart and figure out how it works, I still wouldn't know if my particular lock were secure or not, because I have not seen enough locks to know if this particular one is good or not.
Anytime this condition arises, we replace our own lack of knowledge with a trust in experts. We have to defer the judgement of security worthiness to an expert we trust, in which case we are again disinter-mediated from knowing if the lock is actually secure or not. We all trust *someone* with very specific knowledge to help us make decisions, whether that be medical, scientific, security or otherwise, and in each of those cases, we can find examples of where the expert has let us down.
As systems become more inter-connected and more dependent on standard components, they also become more difficult to diagnose. Problems in one seemingly benign part of the system can affect it and render it unusable, and now those parts may be spread around virtual datacenters and servers. We need OS guru's now more than ever, but it's also expected that those guru's know many different technologies (hence, DevOps and other automation-oriented skills). It's the corollary to what's happening in development: one developer can build more software faster than ever before, but they must also be knowledgeable in a wider range of technologies.
OP mentions a few of the factors that help achieve better software (very good, motivated developers; orientation towards quality, etc). But the most important one was left out: customers willing to pay what it costs to get quality software, and their ability to spot high quality software up-front (during sales cycle). Until that happens, the quality will continue to be poor, because as OP notes, the cost will increase (driving customers away from higher-quality) and the lack of visibility to higher quality will keep them from getting it (ie, ability to recognize a better quality product during sales cycle and pay the extra price knowing they'll actually get higher quality out of it).
Microsoft does something positive; Slashdot readers complain.
Yeah right dude, Steve Jobbs certainly knows nothing about marketing.
Let's face it, the best tech companies out there are run by tech guys.
Bob Lutz is dead-on. Several companies I've worked for were run by the sales guys, and they ran the businesses into the ground by focusing on short-term profits and allowing their products to languish and eventually become irrelevant. They failed to see that investing in good technology and having a vision would ultimately give you an even larger market share. Just like Apple and John Sculley. Sure he got the company back on solid ground, but he couldn't maintain it because he wasn't a visionary tech guy. When they brought Jobbs back again, we all got iPods, iPhones, Macbook Airs and iPads. The PC world has been transformed, and Apple's market cap exceeds Microsoft's.
But the software only has to be 'good enough' for people to buy it, so there's no ammunition for developers to use to get a better schedule.
I've reflected on this problem quite a bit, and I can't seem to get past "Customers are getting what they are demanding," which is to say "not much."
None of the contracts or RFP's I see are demanding performance measures, quality measures, detailed functional requirements, etc. Nor do I see customers diving into the product and really trying it out before they buy, or comparing the competing products hands-on. Our customers purchase based on limited demos run by the vendors themselves, and those making the purchasing decisions don't have enough experience to thoroughly evaluate a product, nor do they seek the expertise of those who can. In the end, purchase decisions are made with very weak product knowledge, and create contracts that are weak on details (but strong on delivery dates).
This results in frustration all around. Vendors have to deliver what the customer wants, but can't figure out what they want until after they buy it, try it, and then complain it doesn't work they way they want. Customers unwittingly purchase vaporware from vendors. The development teams are asked to deliver functionality with little or no guidelines. Target dates for delivery are off by months. In my opinion, this occurs simply because the customer wasn't clear on what they wanted, didn't make those demands clear in their contract, and didn't make a knowledgeable purchase decision.
Which leads to no time for testing, compressed timelines, no ammunition to do it right, no clear budget or tracking of the costs, and on and on.
At least in my field.
I learned to program in BASIC, on an Apple ][+, back in the early 80's when I was 10 or 11. I loved it, but I started wondering how programs like word processors could access a large document in RAM, and work with files bigger than available memory, and other mysteries...which led me to learn C (with a classic Borland C compiler) at 15, and eventually to a CS degree.
In my case, BASIC (and I did LOGO too) didn't ruin me, it made me more curious and moved me into the more complex languages. When I got to college, data structures class was a piece of cake, as I'd already done linked lists and other structures while learning C, and I could easily deal with pointers and pointer arithmetic, multiple indirection, function pointers, and more. I feel a debt of gratitude to the humble BASIC language.
Just a couple weeks ago, I started teaching my son Apple BASIC from a web-based Apple BASIC emulator, hoping that he'll be as excited about programming as I was.
I second this! This is exactly what's keeping most businesses I talk to from using it. Because of the lack of standards, your implementation either isn't compatible with everyone, or if it is you provide a bunch of really complex options that only PhD's understand.
This also produces fear...IT management doesn't understand all those options and the implications of one over the other, and don't want to be held accountable for encryption that doesn't work.
Until there is a simple, uniform and free way to implement certificate authentication, it's just going to wallow.
This is what they were saying 2 years ago, that the megapixel wars were over, that the sweet spot was 8MP. HAH.
Remember when 22MP was what you bought in a $30,000 digital back camera? At the same time, the Canon 1D line was 10MP or so. Um, yeah that was only 5 years ago.
I say no, the megapixel wars are definitely NOT over yet.
The other thing mentioned here is a concentration on quality. That's been happening hand-in-hand with the megapixel wars. So the latest in the Digic line of processors can both handle more pixels, faster, and produce better quality images at higher ISO, all at the same time. I would expect that to continue as well.
True, at some point physics will take over, as it was supposed to YEARS ago in the microprocessor market, but now we have 45micron processes that nobody dreamed of. The same will happen for CCD's and so on. Who knows where it will end.
Steam is so great, I've literally never heard of it until this article today.
Ah, so it's a way to sell more machines to run more infrastructure software (also sold) which companies think will increase their scalability, which they don't really need because most of them are never going to have the amount of business that would force them to scale, where simple client-server software would suffice while they're going down the tubes.
Guess you've never been to the other side of that. The other side of that is a set of applications that are good enough to win your company the business, but that don't work together at all.
You can say "you should have thought about that in the first place, good design would have cleared that up" but good, thorough design that attempts to make everything work together flawlessly results in long development cycles and lost business.
Our company won, we built the best products and got the market share, and now we've got a set of applications that our customers expect and want to work together, and we are struggling to deliver it.
SOA is one way we can help with this problem. We can add SOA interfaces to each application, and start constructing the one integrated product our customers want, in an orderly way, quickly, without re-writing all our apps, and piecemeal. We can add SOA interfaces to each application's back end, one at a time, prove it works, and then work on meta-applications to combine the results.
We built much of the software to handle this ourselves. There are OSS options for most pieces of this architecture if we wanted to use an ESB engine (check out Mule for example), and with our VM environment we should not need significant investment in infrastructure. We just need time to build it, and hence corporate wherewithal.
SOA (and ESB and the like) in-and-of themselves will not provide a solution to enterprise integration, any more than the EAI engines of 10 years ago, but at least they provide a common technology to build around so that other developers can tap into the functionality of our applications.
The same kind of arguments were made in support of C: that hard-to-maintain spaghetti code is not the language's fault, it's the developer's. But the bottom line is this: if the language fails to enforce some basic good coding practices, then the code won't be easy to maintain. It's difficult, if not impossible, to find and hire the kind of talent across your organization that can keep the code maintainable and readable. It's just as hard to review all the code to ensure it meets your development standards, and train junior engineers on how to do it properly. Therefore, just having Perl or C code to maintain means you are almost guaranteed to have harder-to-maintain code, that has to be worked by more-senior developers. Those very developers are who you need plugged into new projects that require senior developers and out-of-the-box thinking. If they are tied up cleaning up the spaghetti that other engineers produce, you lose productivity across your organization, and your senior guys want to quit.
Java, .NET and other shiny new languages help in significant ways in making software products easier to develop and maintain. So Even though I can code nice C code, and I can handle pointer arithmetic and memory allocation well, doesn't mean I can find all the resources I need to ensure that same level of development in all my products.
iTunes is the worst, IMO. It seems no matter how many times I patch it, just days later there's another patch. Every patch is a full download and reinstall, and every patch re-installs the damn Quicktime thingy in my taskbar. And now it sends me Safari too. Ugh!
I'm with you. I like Vista just fine. I have one annoyance with it, but then I had some with XP too. My XP installation was starting to feel it's age and that's when I replaced it with Vista.
Don't get me started with Linux annoyances, which I noticed there is no book for BTW. Funny that. NAAAAAW! No annoyances with Linux or any other unix, they all work just perfectly and never ever have a problem or lack of functionality. Excuse me while I sneeze -- b*llsh!t!
Go ahead, call me fanboy or whatever, but in the end Linux still disappoints me more than Windows does. I still get more done with my Vista box than I ever did with Linux on my desktop. (Oooo, Slashdot blasphemy!)
None of these API's just fell out of the sky and landed in Microsoft's lap; they were built tediously and at great expense. And let's not forget that these are not the types of functions that are really making Microsoft top dog. Microsoft is top dog due to social and business factors, not API's and technical ones.
Funny that there are endless discussions about the poor technical quality of Microsoft's products, and at the same time rants that Microsoft is gaining an unfair advantage via technical means. Either the technology is good or it's not. If this case is valid, then we must also acknowledge that Microsoft's technology is king too.
I suppose they would also sue Microsoft if the language was left our of their products, because that would be language discrimination.
When your installed base consists primarily of smaller groups of art-related positions within a larger organization, it's not hard to make the switch is it? The corporation's custom apps, business apps and network apps all reside firmly on Windows machines.
The Mac machines, in contrast, are small in number and largely standalone. All they have to do is replace the machine, upgrade the commercial software (largely Adobe suite and/or Quark), and you're done.
The thing that is scaring bright technologists away from the field is simple: businesses see IT developers and other technologists as nothing more than factory-line workers of our day. We are interchangeable parts, and therefore not worth as much to the company as upper management is...or middle management even.
So for our careers to grow, ironically, business pushes the brightest technologists to management, leaving an even-larger gap in capable engineers. There is nowhere else for us to grow into (case in point, I've been a Senior Engineer for my entire 10-year IT career, there's no higher technology position to go to).
In fact, development and other complex IT tasks require a type of worker that is not comparable to any other field. They are largely self-managed, and must work out engineering complexities unheard-of in other fields. The bredth of technologies and knowledge are only comparable to the most high-knowledge careers such as law, medicine, and bio-tech.
Further, the work these technologists do, and the quality of that work, directly affect the bottom-line of the technology company. The loss of a single key technologist can have a ripple-effect that is hard to quantify, but that definitely impacts the bottom line. But due to the manufacturing-centric business practices of corporations and the MBA management crowd, these dollars are never realized. Hence, management views these workers as an expense, and not generating any revenue. Conversely, sales staff, who produce nothing re-sellable on their own, and who cannot affect the cost-basis of a company much, are revered by upper-management because of the positive cash-flow realized by landing sales, and their salaries and position within the company are commensurate.
Until IT business management practices catch up to the new business landscape, they will continue to scare off the brightest talent, forcing the best technologists into management or other positions in order to see their careers continue to grow. I think Google and a few other top-tier technology companies get this, but the remainder continue to flounder in the IT landscape.
You can see this ultimately realized by "dad's advice": You don't want to be doing the work, you want to manage. Anyone can do the work.
No. Not everyone can do the work in this field, just as not everyone can be a bio-tech engineer, and until this attitude changes from business to home, IT won't attract a large crowd.
I remember it well. For my 12th Birthday, I wanted a computer. I went to the store (Montgomery Wards I think( and tried out several, and it became a bakeoff between the Sinclair and the Vic20. I chose the Vic in the end because it had a full-size keyboard. I thought the Sinclair would be difficult to type on.
Eventually I added a Commodor RGB monitor and a tape drive. I got the tape drive at Toys-r-Us (yeah, they used to sell home computers) and paid $60 for it. That was something like 1984.
Not long after I upgraded to the C64, and eventually a PC.
I have to agree. I buy almost all of my software online these days, and was SHOCKED that couldn't buy a license for WOW online. You can't buy a massivly multiplayer ONLINE game online?
My friend gave me the disks to install with, and why not? It's a subscription service to start with. The idea that I then had to pack up and go to the store and buy a copy was absurd.
Heck, I didn't even think you'd have to pay for the software, since it's an online monthly fee anyway, just roll the cost of the software into the online fee and be done with it.
In the end I did have to go to the store, just so I could have the license code off of the disk sleeve. I've never actually used my disks, or even read the box.
And think of the viral-marketing referral that went on there.
Imagine an article about your life appears on Wikipedia for millions to read, an article that will last forever and may very well shape opinions about you as a person. The author of this article in Wikipedia has never met you, and doesn't necessarily like you or what you've done with yourself. They author the article, you see errors or omissions, but aren't allowed to edit them. Worse, people who definitely don't like you try to chime in, those who definitely do like you fight back...but they're all wrong.
Okay, so that's extreme, and we're not politicians. I don't know if the articles in question were negative or misleading, but how can someone sitting at a terminal in Nashville TN, like myself, possibly know what XYZ politician is really like, what they've really done, who they really are? I don't know these people, and my only contact with them is through a decidedly limited and biased media, soundbytes and highly-edited speaches.
Of course the idea that politicians can edit their record is creepy and could lead to Orwelian misinformation, but put yourself in their shoes for a minute...it may not be all that difficult to understand.
Timbert
Modern software development relies on an ever-expanding list of external factors. Case in point, our application ran perfectly fine until one day, it started crashing. The errors gave us no clue to the problem. As far as we could tell, the software was fine. Our software ran on top of a J2EE server, which runs on top of a JVM, which runs on top of an OS, which runs on top of hardware. It relies on database drivers, which connect over a network, which run against a database, which itself relies on the os, which runs on hardware. The J2EE server, of course, relies on the web server, and the driver to make the two work together. They all rely on the firewall for security, and the crypto flavor-of-the-year for HTTPS security.
All of these pieces can be culprits in the issue, but only one of those is in your direct control, that being your source code.
In the end, a MS patch against the OS caused issues in the JVM which caused issues in the J2EE server, causing our JDBC connections to lock up and fail. To find that we had to check every piece mentioned above. Swapping out to another JVM fixed the issue, but was risky because the source, which we purchased from a third party, was not qualified to run on the newer JVM.
Now imagine unwinding all of that in court. Who's fault is it? MS is just patching their OS. Sun can't be held liable for a bug in a JVM that's no longer being maintained, and was not certified to run on the newer OS patches, the J2EE server can't be upgraded because the app isn't built to run on it.
The fact of the matter is that you can't hold the engineer who designed the break pads responsible for a crash if the driver can switch out the engine, transmission, wheels, tires, diffs, etc., and can drive past the limits of the design of the automobile.
Ideas like holding software developers or development companies accountable will lead to far less software development, more expensive software, with very hard vendor-imposed limitations, like "by agreeing to this EULA you agree to run this software on a dedicated, vendor-approved machine, with the os of our choosing, and you may not patch the os or hardware drivers unless it is cleared by us."
No way. I'll take what we have.