Microsoft is actually making a decent stab at the problem with WMI, a sort of big brother to SNMP. Unfortunately the implementation is complex, non-standard, and up until now nobody has really used it for the type of remote instrumentation that this article talks about.
Actually, they WERE making a good stab at this - five or so years ago. Since then, the nature of where they're trying to go with this has changed, nearly the entire project-team has disbanded (and was reformed with a different focus), and they've stopped pushing for WMI-related WHQL requirements - thereby nipping the WMI-centric management idea in the bud.
To correct a few other misconceptions you stated... It really isn't all that complex; it's essentially an object-oriented database, with object instantiation, linkage, inheritance, an event system, and various other spiffy things. It IS most definitely standard; see the DMTF and their specifications for CIM and WBEM. And yes, SOME companies actually do make use of WMI for remote "agent" type system-monitoring; the company I work for makes extensive use of WMI for monitoring of remote servers, and proactively initiating Alerts that are sent out to our own servers letting us know when critical components of our customers' fault-tolerant servers have gone awry.
Don't get me wrong, Microsoft's WMI has had a LOT of problems in the past - the service crashing, memory leaks, lost notifications, etc. - but it's relatively stable now. And it's a fricking great idea in theory, as per the CIM/WBEM standards...
Consider if you will for a brief moment the vast difference between the average executive and the average programmer. Programmers are generally broad-picture thinkers who solve largely complicated problems that regular folks can't possibly wrap their heads around.
I'm afraid I hafta disagree here. Average programmers are generally straight-line, "inside the box" thinkers. Point them towards a target, give them some basic parameters describing how to get from here to there, and let them loose.
The type of person you are referring to are (many) Senior-level Engineers, (most) Project/Technical Leads, and/or (nearly all) Architects. THESE are the people capable and willing to look at the "big picture" when it comes to their work; most others have neither the will nor the ability to take a step back and take the time required to see the forest through the trees. Give them a tree - their tree - and they're perfectly fine. Give them the "whole picture" you refer to, and they quickly get lost, most oftentimes trying to concentrate on the 1232834928374 individual instances of trees which make up this forest.
You may not realize it, but you've hit the nail on the head here. The biggest problem with SW Development is that too often the engineers do not understand the user perspective. It really doesn't matter what development methodology you use, if you use Use Cases or Agile Programming or whatnot - if the people writing the software don't understand their users' perspectives then all of the problems people've been mentioning will come up.
What is the biggest reason for "feature creep"/changing requirements?? Because the engineers built what they wanted, NOT what the customer wanted. Instead of trying to shoehorn a customer's usage of a tool into your idea as to how a tool should be implemented - and this is what pretty much all software is, a TOOL meant to help people perform some task easier, NOT an end in and of itself - understand what the customer wants to do with the tool, understand the customer's viewpoint (including such things as average level of technical expertise, currently-existing methodologies, etc.), understand the desired end result. And while Unit Testing is great from an Engineering perspective, USABILITY TESTING is at least as important to your end-user/customer. USE your tool the same way a customer would. If you were doing the customer's job, what sorts of things would you want to do? What would be the easiest way to do them?
Nearly every time I've seen a "bad" piece of software developed, it's been because the developers refuse to (or are incapable of) place themselves in the shoes of their customer. (And even for internal projects, you should think of your end-users as your customers, dammit.) And then when discussing things with their customers (or Management, who believe it or not oftentimes DOES understand your customers viewpoint, especially those creepy Marketing Droids), the Engineers responsible hold fast to their way of thinking and place the viewpoint of the SOFTWARE above the viewpoint of the CUSTOMER. Bad engineers, BAD!!
As a SW Engineer myself, I realize it's difficult to raise your head up out of the code you're working on, take a step back, and evaluate your tool from the perspective of a non-engineer. It is well worth the effort, however. Your customers will thank you for it, your management chain will reward you for it, and those peers whose opinion matters will respect you for it.
(And for the more obtuse among the Slashdot readership, yes, Feature Creep / Changing Requirements IS the primary reason most adequately-run projects are late. Nearly everything else is just fluff which can be scheduled around. Designing software which does not meet the ends of the end-users, however, should be considered a Mortal Sin.)
Re:Read the fake suit ... then write your Senator
on
P2P Bits
·
· Score: 2, Informative
Furthermore, try to take the time to sign up to the "EFF Action Center". Then, instead of wasting time composing messages on Slashdot to complain about the idiocy of this law, spend your time editing the text of the barebones message EFF provides for you, so as to increase its impact. While sending one of a whole slew of identical emails definitely will show your support for this matter, a well-written (be nice!) "personal" note would have even more effect. Bonus points if you can point to specific companies in your local state that would be adversely affected by this law...
Slashdot Mirror
To correct a few other misconceptions you stated... It really isn't all that complex; it's essentially an object-oriented database, with object instantiation, linkage, inheritance, an event system, and various other spiffy things. It IS most definitely standard; see the DMTF and their specifications for CIM and WBEM. And yes, SOME companies actually do make use of WMI for remote "agent" type system-monitoring; the company I work for makes extensive use of WMI for monitoring of remote servers, and proactively initiating Alerts that are sent out to our own servers letting us know when critical components of our customers' fault-tolerant servers have gone awry.
Don't get me wrong, Microsoft's WMI has had a LOT of problems in the past - the service crashing, memory leaks, lost notifications, etc. - but it's relatively stable now. And it's a fricking great idea in theory, as per the CIM/WBEM standards...
I'm afraid I hafta disagree here. Average programmers are generally straight-line, "inside the box" thinkers. Point them towards a target, give them some basic parameters describing how to get from here to there, and let them loose.
The type of person you are referring to are (many) Senior-level Engineers, (most) Project/Technical Leads, and/or (nearly all) Architects. THESE are the people capable and willing to look at the "big picture" when it comes to their work; most others have neither the will nor the ability to take a step back and take the time required to see the forest through the trees. Give them a tree - their tree - and they're perfectly fine. Give them the "whole picture" you refer to, and they quickly get lost, most oftentimes trying to concentrate on the 1232834928374 individual instances of trees which make up this forest.
You may not realize it, but you've hit the nail on the head here. The biggest problem with SW Development is that too often the engineers do not understand the user perspective. It really doesn't matter what development methodology you use, if you use Use Cases or Agile Programming or whatnot - if the people writing the software don't understand their users' perspectives then all of the problems people've been mentioning will come up.
What is the biggest reason for "feature creep"/changing requirements?? Because the engineers built what they wanted, NOT what the customer wanted. Instead of trying to shoehorn a customer's usage of a tool into your idea as to how a tool should be implemented - and this is what pretty much all software is, a TOOL meant to help people perform some task easier, NOT an end in and of itself - understand what the customer wants to do with the tool, understand the customer's viewpoint (including such things as average level of technical expertise, currently-existing methodologies, etc.), understand the desired end result. And while Unit Testing is great from an Engineering perspective, USABILITY TESTING is at least as important to your end-user/customer. USE your tool the same way a customer would. If you were doing the customer's job, what sorts of things would you want to do? What would be the easiest way to do them?
Nearly every time I've seen a "bad" piece of software developed, it's been because the developers refuse to (or are incapable of) place themselves in the shoes of their customer. (And even for internal projects, you should think of your end-users as your customers, dammit.) And then when discussing things with their customers (or Management, who believe it or not oftentimes DOES understand your customers viewpoint, especially those creepy Marketing Droids), the Engineers responsible hold fast to their way of thinking and place the viewpoint of the SOFTWARE above the viewpoint of the CUSTOMER. Bad engineers, BAD!!
As a SW Engineer myself, I realize it's difficult to raise your head up out of the code you're working on, take a step back, and evaluate your tool from the perspective of a non-engineer. It is well worth the effort, however. Your customers will thank you for it, your management chain will reward you for it, and those peers whose opinion matters will respect you for it.
(And for the more obtuse among the Slashdot readership, yes, Feature Creep / Changing Requirements IS the primary reason most adequately-run projects are late. Nearly everything else is just fluff which can be scheduled around. Designing software which does not meet the ends of the end-users, however, should be considered a Mortal Sin.)
Furthermore, try to take the time to sign up to the "EFF Action Center". Then, instead of wasting time composing messages on Slashdot to complain about the idiocy of this law, spend your time editing the text of the barebones message EFF provides for you, so as to increase its impact. While sending one of a whole slew of identical emails definitely will show your support for this matter, a well-written (be nice!) "personal" note would have even more effect. Bonus points if you can point to specific companies in your local state that would be adversely affected by this law...