It's clear Enderle provokes a strong reaction from the rabble (I'm one of the rabble, back up there), but the blog entry is a good one, worthy of discussion, even as framed.
If Linux is to be taken seriously and adopted within large corporations, it does need to address those five points specifically. You can't convince upper management of the merits of your argument by using your Crazy Fist Number Eleven Slashdot Flame technique, so address those concerns rationally and in terms of business concerns, or you'll lose.
Widespread adoption among consumers should be ruled out categoricallly, until you can download a distro in one shot, and have it find your wireless adapter, Bluetooth adapter, and all your laptop goodies, without once have to su-su-sudo a single command line. For any laptop coming out of Dell or Toshiba, sold at Circuit City or Best Buy, and so forth. And there ain't a single distro that can do it today.
Unfortunately, in-house software dev rarely rates a usability engineer or whatever rarified form of analyst you propose. I understand the basic issue here, though: the original writer never received the kind of indoctrination you get in a more professional shop. This is not really a knock as much as it is praise for the long-gone development team of AT&T, for example, that had excellent day-one training for new hires.
We are almost out of analysis for the first iteration of a major internal project, global in scale and scope. We have over 1200 user requirements, and we're going to get more over time. The requirements gathering is always the easy part. The hard part is analyzing them and trying to figure out if we understand what they said a week later. Now try to get consensus among four continents, and you can see that it's really just communication and facilitating discussion. It's no wonder people fail to do it, because it's so diametrically opposed to CS course study.
That actually sparks a thought (take note!): what if as part of your CS course work you had to take a class that involved lots (and lots) of interviewing people? Would criminal justice departments or psychology departments have that? We could sure use a re-orientation around the human elements of requirements and analysis.
The one reply I hadn't seen involves what may be more common in your workplace: being paid relative to your immediate peers.
Let's imagine what would happen if everyone's salary information suddenly appeared on their office door or cubicle wall. The uprising that would follow would be interesting and justified. The company doesn't want you to know that you're paid less than the other guy, who's slack you've been picking up for the last two years. The company figures it's a wash anyway: they probably don't like overpaying for mediocre performance either, but they have you so it averages out *to them*.
Suddenly informed, you now have the advantage of knowing that you're underpaid just within the company, apples to apples, by 25%. The company can no longer average it out: it has to cut the loser's pay or bump yours, if it chooses to continue averaging it out.
If the loser doesn't like the pay cut, separation makes it easier to average it out. And the playing field is truly level.
I'm not missing the point, and I think you need to understand how a supply chain works before continuing the debate. There is a price point that must be met before making something is more worthwhile than sitting idle. Making "something" is definitely not better than sitting idle in all cases.
Idle time in a fab is no less an issue for AMD than it is for a major pharmaceutical that needs to produce as much anti-cholesterol drug as possible before patent protection runs out. However, it is far easier to keep an idle room clean than it is to maintain a working production room's cleanliness, and costs for a line still have to factor into the overall account the cost of supply chain. In this respect, CPU manufacture is no different than any other supply chain manufacturer.
I disagree. Idle time in any manufacturing operation can be viewed as an opportunity. For one thing, retooling to go to 65nm or 45nm or 30nm takes time, which might as well be spent earlier rather than later. Another consideration is maintenance, which is not retooling but repair and perhaps prep work for a future retooling effort if necessary.
Cranking out processors just to give people something to do is not really minimizing costs, unless you're paying people to be idle. Even then, the energy and raw material costs probably have their own break-even points that require x-number of CPUs to be sold before it becomes better to run the operation than not. Because this is a new CPU, some investment went into design and possible minor retooling anyway, so that determination was already made.
The fact remains, until 65 and 45nm procs emerge, and AMD moves to a shared cache, Intel will have the perf lead, period. These things happen, so it's best to put on your consumer hat and enjoy the fruits of competition... the zealotry has no place in business.
I don't mean to denigrate your choice of architectural platform, but you don't indicate your level of authority/ approval of this sort of thing. I'll just sketch out how it works for very large companies and you can cut out the middle layers for your own purposes.
Accounting, as a department, would work with IT to locate the best application for their requirements, with respect to the following: 1) fitness with current or predicted ERP solution(s) if extant, so you don't buy something that doesn't work with SAP, for example; 2) fitness with current architectural plan or standards, so you don't bring in an AS/400 into a Windows-only shop or a one-off solution (i.e. requiring an Oracle database in a DB2 shop); 3) fitness with what other parts of the company are using, so you don't duplicate the efforts of another part of your company.
I could only imagine a scaled down version, but it will probably be something like this: the IT person charged with finding the app should bring in an accounting rep right now, such that the rep has the authority or can acquire the authority to purchase a solution. Then your IT point man should be pulling down all viable candidates that fit the constraints, and then running demos and shootouts based on real user requirements (I'm assuming IT has their requirements being met during the selection of candidates).
I wasn't seeing this in the original request, and I've been through enough of these to recognize when a solution may be getting anointed without enough due diligence of the other, more critical issues. Sorry to break it to you, but if the best package for your business happens to be a Windows-only app, you need to get over your Spheniscidaen bias and do the right thing by your accounting folks. The best app for them may not be the best app for IT, but that's why you get paid the big bucks, fella.
Most of you probably know all this and I'm likely just stating the obvious.
RIAA uses an old but effective technique to keep their royalties coming: information hoarding. A fully-transparent accounting of costs per CD, traced back to what the artist gets and including taxes, etc, would neuter most of the arguments or at least put them on the same playing field for fair comparisons.
Once this is done, it becomes easy to look at artist output as the sum of recording studio time plus expenses, then promotion costs, and so forth down to distribution which, then, becomes very small as a line-item cost. Once the cost components are transparent, effective arbitrage pushes these costs down as well.
I can remember playing Lode Runner on my Apple//e and getting to some odd level where, basically, you just died endlessly because you could never maneuver out of danger.
Or Wizardry (hacked of course, also on Apple//e) where you never got to the last level and finally realized you're never going to get back those last eight months.
Thanks for the reply. I think my twelve years of IT experience, and never having missed a date, elevates me past the rookie status, but I see it holds no water with you.
I'm glad you picked up on that, perceptive. I put that out there to give myself the wholly-unneeded stress of hitting the date. But we *are* going to make that date.
We're intending to spiral out, iterating through each module, so it isn't a waterfall. Or, maybe it's a whirlpool: as we prototype each module, we're coming in with a plan of attack on what our end results will be. We intend to -- and have already done this in some cases -- map out precisely what "magic" needs to happen. It might as basic as creating a copy of a record to show record differences to the user (approving changes by comparing before/ after versions), or stating that disparate elements can be grouped together for approval (which is a complex version of the previous requirement).
All I'm saying is that it's not enough to say "the system must provide a means to allow a user to collate any revised objects into a group for approval". You have to go a little further and discuss or even solve how that can be done, if you're going to leverage the programmers on the project.
-BA
Software is neither "hard" or "easy"
on
Why Software is Hard
·
· Score: 5, Insightful
Implementing a good design is usually half the battle. Creating a good design is usually the other half, but in practice, a solid design is almost always the part that gets skipped. Let me bore you with a brief anecdote.
I have a large, global project underway. User requirements are done and have been done, and we're turning those requirements into things we can code or deliver ("View a workorder", "Print asset detail", "Group revisions into single document"). Of that, we have 150 odd deliverable items, not to mention all the fit/ finish work we may have to do, and all of this barely touches on reports, security roles for users, etc.
The reason we're going to make our date, despite the 1280 discrete requirements we need to test, is that we've taken the time to look at the requirements from a few different angles and come up with a solid design plan, before even thinking about implementation. Each piece will build on another, really hard parts are identified early, blockers and such are flagged ASAP. We know things will emerge that we didn't expect, but we've got the biggest chunks identified and working together on paper. We have the flows mapped out, exceptions and variations listed, and a user group that has to sign off on every iteration of the incremental build (we're spiraling out functions and features).
The only thing "hard" about all of this is the incessant thinking about the details, and discipline required to focus on the un-fun part of software construction, i.e. the planning and design walkthroughs. The itch to code something already is growing, but delayed gratification means that when the time comes to actually write something, the design will almost certainly lead to a working, if not optimal, solution. We can refactor as we go, but it needs to work completely before it can work efficiently.
I've been following Chandler off and on, somewhat through Spolsky's references to it and some stray links around the web, and sounds like design didn't go deep enough into what it'll really take to build some of the pieces.
It's such a naive concept I'm almost embarrassed to bring it up, but I'm not seeing how this breaks down so I offer this as a "softball" comment for an econ major to crush with an explanation.
Why couldn't the US Gov't roll back prices and value by an order of magnitude and print/ mint new money? Your $50k salary is now $5k a year, but gas is now 20 cents a gallon and milk is now 30 cents a gallon (ironic). Then your dollars and pennies are now worth what they should be.
-BA
Re:Let it rest in peace!
on
AmigaOS 4
·
· Score: 1
Umm, the Power CPUs routinely outperform x86s across the board. And what my AIX boxes can do after a single day of configuration is not even possible with a rack of Dell blades and the VM platform of your choice. Power5 CPUs are what grownups use.
The key concept is the interactivity. The idea of interacting with a dead relative on a borthday is not so much creepy as it is incredibly sad. The primary reason we're able to carry on as normal people is the natural fade of intense emotions over time.
If you were continually reminded every year of some tragic loss, with the same intensity as when it first occurred, would that be a benefit or detriment to your life? This is not a choice to be made lightly, and it's certainly not the promotional use case I'd like to hear if it does evolve into a product-service.
Welcome to 2007. You might also consider upgrading from Windows 95, buying a PC with a hard drive bigger than 5Gb, and using an MP3 player with a screen.
So some schlep takes a pair of prime numbers, plops a "2" in the middle of them, and calls this a twin prime? Yeah, I think I'm with Dopey Reply Number One on this, try jamming a a third prime in there and call me when it's done. 350 degrees for twenty minutes.
Oh, wait, my wife tells me the whole number is a prime. Well, that's why she has the Master's in math and I make the money.
Slashdot Mirror
It's clear Enderle provokes a strong reaction from the rabble (I'm one of the rabble, back up there), but the blog entry is a good one, worthy of discussion, even as framed.
If Linux is to be taken seriously and adopted within large corporations, it does need to address those five points specifically. You can't convince upper management of the merits of your argument by using your Crazy Fist Number Eleven Slashdot Flame technique, so address those concerns rationally and in terms of business concerns, or you'll lose.
Widespread adoption among consumers should be ruled out categoricallly, until you can download a distro in one shot, and have it find your wireless adapter, Bluetooth adapter, and all your laptop goodies, without once have to su-su-sudo a single command line. For any laptop coming out of Dell or Toshiba, sold at Circuit City or Best Buy, and so forth. And there ain't a single distro that can do it today.
-BA
Unfortunately, in-house software dev rarely rates a usability engineer or whatever rarified form of analyst you propose. I understand the basic issue here, though: the original writer never received the kind of indoctrination you get in a more professional shop. This is not really a knock as much as it is praise for the long-gone development team of AT&T, for example, that had excellent day-one training for new hires.
We are almost out of analysis for the first iteration of a major internal project, global in scale and scope. We have over 1200 user requirements, and we're going to get more over time. The requirements gathering is always the easy part. The hard part is analyzing them and trying to figure out if we understand what they said a week later. Now try to get consensus among four continents, and you can see that it's really just communication and facilitating discussion. It's no wonder people fail to do it, because it's so diametrically opposed to CS course study.
That actually sparks a thought (take note!): what if as part of your CS course work you had to take a class that involved lots (and lots) of interviewing people? Would criminal justice departments or psychology departments have that? We could sure use a re-orientation around the human elements of requirements and analysis.
-BA
The one reply I hadn't seen involves what may be more common in your workplace: being paid relative to your immediate peers.
Let's imagine what would happen if everyone's salary information suddenly appeared on their office door or cubicle wall. The uprising that would follow would be interesting and justified. The company doesn't want you to know that you're paid less than the other guy, who's slack you've been picking up for the last two years. The company figures it's a wash anyway: they probably don't like overpaying for mediocre performance either, but they have you so it averages out *to them*.
Suddenly informed, you now have the advantage of knowing that you're underpaid just within the company, apples to apples, by 25%. The company can no longer average it out: it has to cut the loser's pay or bump yours, if it chooses to continue averaging it out.
If the loser doesn't like the pay cut, separation makes it easier to average it out. And the playing field is truly level.
-BA
mod parent +1 funny, good insight!
I'm not missing the point, and I think you need to understand how a supply chain works before continuing the debate. There is a price point that must be met before making something is more worthwhile than sitting idle. Making "something" is definitely not better than sitting idle in all cases.
-BA
Idle time in a fab is no less an issue for AMD than it is for a major pharmaceutical that needs to produce as much anti-cholesterol drug as possible before patent protection runs out. However, it is far easier to keep an idle room clean than it is to maintain a working production room's cleanliness, and costs for a line still have to factor into the overall account the cost of supply chain. In this respect, CPU manufacture is no different than any other supply chain manufacturer.
-BA
I disagree. Idle time in any manufacturing operation can be viewed as an opportunity. For one thing, retooling to go to 65nm or 45nm or 30nm takes time, which might as well be spent earlier rather than later. Another consideration is maintenance, which is not retooling but repair and perhaps prep work for a future retooling effort if necessary.
Cranking out processors just to give people something to do is not really minimizing costs, unless you're paying people to be idle. Even then, the energy and raw material costs probably have their own break-even points that require x-number of CPUs to be sold before it becomes better to run the operation than not. Because this is a new CPU, some investment went into design and possible minor retooling anyway, so that determination was already made.
The fact remains, until 65 and 45nm procs emerge, and AMD moves to a shared cache, Intel will have the perf lead, period. These things happen, so it's best to put on your consumer hat and enjoy the fruits of competition... the zealotry has no place in business.
-BA
I don't mean to denigrate your choice of architectural platform, but you don't indicate your level of authority/ approval of this sort of thing. I'll just sketch out how it works for very large companies and you can cut out the middle layers for your own purposes.
Accounting, as a department, would work with IT to locate the best application for their requirements, with respect to the following: 1) fitness with current or predicted ERP solution(s) if extant, so you don't buy something that doesn't work with SAP, for example; 2) fitness with current architectural plan or standards, so you don't bring in an AS/400 into a Windows-only shop or a one-off solution (i.e. requiring an Oracle database in a DB2 shop); 3) fitness with what other parts of the company are using, so you don't duplicate the efforts of another part of your company.
I could only imagine a scaled down version, but it will probably be something like this: the IT person charged with finding the app should bring in an accounting rep right now, such that the rep has the authority or can acquire the authority to purchase a solution. Then your IT point man should be pulling down all viable candidates that fit the constraints, and then running demos and shootouts based on real user requirements (I'm assuming IT has their requirements being met during the selection of candidates).
I wasn't seeing this in the original request, and I've been through enough of these to recognize when a solution may be getting anointed without enough due diligence of the other, more critical issues. Sorry to break it to you, but if the best package for your business happens to be a Windows-only app, you need to get over your Spheniscidaen bias and do the right thing by your accounting folks. The best app for them may not be the best app for IT, but that's why you get paid the big bucks, fella.
-BA
Most of you probably know all this and I'm likely just stating the obvious.
RIAA uses an old but effective technique to keep their royalties coming: information hoarding. A fully-transparent accounting of costs per CD, traced back to what the artist gets and including taxes, etc, would neuter most of the arguments or at least put them on the same playing field for fair comparisons.
Once this is done, it becomes easy to look at artist output as the sum of recording studio time plus expenses, then promotion costs, and so forth down to distribution which, then, becomes very small as a line-item cost. Once the cost components are transparent, effective arbitrage pushes these costs down as well.
-BA
The translation of this concept from Russian to English, of course, is "Allofmp3"
-BA
I can remember playing Lode Runner on my Apple //e and getting to some odd level where, basically, you just died endlessly because you could never maneuver out of danger.
//e) where you never got to the last level and finally realized you're never going to get back those last eight months.
Or Wizardry (hacked of course, also on Apple
-BA
Thanks for the reply. I think my twelve years of IT experience, and never having missed a date, elevates me past the rookie status, but I see it holds no water with you.
-BA
I'm glad you picked up on that, perceptive. I put that out there to give myself the wholly-unneeded stress of hitting the date. But we *are* going to make that date.
-BA
We're intending to spiral out, iterating through each module, so it isn't a waterfall. Or, maybe it's a whirlpool: as we prototype each module, we're coming in with a plan of attack on what our end results will be. We intend to -- and have already done this in some cases -- map out precisely what "magic" needs to happen. It might as basic as creating a copy of a record to show record differences to the user (approving changes by comparing before/ after versions), or stating that disparate elements can be grouped together for approval (which is a complex version of the previous requirement).
All I'm saying is that it's not enough to say "the system must provide a means to allow a user to collate any revised objects into a group for approval". You have to go a little further and discuss or even solve how that can be done, if you're going to leverage the programmers on the project.
-BA
Implementing a good design is usually half the battle. Creating a good design is usually the other half, but in practice, a solid design is almost always the part that gets skipped. Let me bore you with a brief anecdote.
I have a large, global project underway. User requirements are done and have been done, and we're turning those requirements into things we can code or deliver ("View a workorder", "Print asset detail", "Group revisions into single document"). Of that, we have 150 odd deliverable items, not to mention all the fit/ finish work we may have to do, and all of this barely touches on reports, security roles for users, etc.
The reason we're going to make our date, despite the 1280 discrete requirements we need to test, is that we've taken the time to look at the requirements from a few different angles and come up with a solid design plan, before even thinking about implementation. Each piece will build on another, really hard parts are identified early, blockers and such are flagged ASAP. We know things will emerge that we didn't expect, but we've got the biggest chunks identified and working together on paper. We have the flows mapped out, exceptions and variations listed, and a user group that has to sign off on every iteration of the incremental build (we're spiraling out functions and features).
The only thing "hard" about all of this is the incessant thinking about the details, and discipline required to focus on the un-fun part of software construction, i.e. the planning and design walkthroughs. The itch to code something already is growing, but delayed gratification means that when the time comes to actually write something, the design will almost certainly lead to a working, if not optimal, solution. We can refactor as we go, but it needs to work completely before it can work efficiently.
I've been following Chandler off and on, somewhat through Spolsky's references to it and some stray links around the web, and sounds like design didn't go deep enough into what it'll really take to build some of the pieces.
-BA
I think the bottom line is you're not providing an explanation, which is all I requested. I wasn't offering a solution.
-BA
That doesn't adequately explains it, it just raises other questions.
-BA
It's such a naive concept I'm almost embarrassed to bring it up, but I'm not seeing how this breaks down so I offer this as a "softball" comment for an econ major to crush with an explanation.
Why couldn't the US Gov't roll back prices and value by an order of magnitude and print/ mint new money? Your $50k salary is now $5k a year, but gas is now 20 cents a gallon and milk is now 30 cents a gallon (ironic). Then your dollars and pennies are now worth what they should be.
-BA
Umm, the Power CPUs routinely outperform x86s across the board. And what my AIX boxes can do after a single day of configuration is not even possible with a rack of Dell blades and the VM platform of your choice. Power5 CPUs are what grownups use.
-BA
The key concept is the interactivity. The idea of interacting with a dead relative on a borthday is not so much creepy as it is incredibly sad. The primary reason we're able to carry on as normal people is the natural fade of intense emotions over time.
If you were continually reminded every year of some tragic loss, with the same intensity as when it first occurred, would that be a benefit or detriment to your life? This is not a choice to be made lightly, and it's certainly not the promotional use case I'd like to hear if it does evolve into a product-service.
-BA
Lemme guess, Butabi brother?
-BA
Welcome to 2007. You might also consider upgrading from Windows 95, buying a PC with a hard drive bigger than 5Gb, and using an MP3 player with a screen.
-BA
Nine cents? That's an economic disincentive if I've ever seen one. Good luck on the hacking.
-BA
... but it's the only place I can install a UT3 server at work and not have the sysadmins find it.
Happy fragging,
-BA
So some schlep takes a pair of prime numbers, plops a "2" in the middle of them, and calls this a twin prime? Yeah, I think I'm with Dopey Reply Number One on this, try jamming a a third prime in there and call me when it's done. 350 degrees for twenty minutes.
Oh, wait, my wife tells me the whole number is a prime. Well, that's why she has the Master's in math and I make the money.
-BA