here's the problem: every day, i make pretty heavy use of machine learning and the other bits and pieces that collectively get referred to as artificial intelligence. as a consequence, i deal with a very large number of fools who are each convinced that their $ALGORITHM is an earth shattering new paradigm for $TASK and clearly is the best thing evar. so you start reading and you realize that in 99.999% of cases, you're staring at something that is some combination of:
a) based on a fundamentally broken assumptions (usually never even stated) b) bad analogies that obfuscate the fact that wheels are being re-invented (usually poorly) c) narrowly defined special case d) broken (provably non-optimal optimization routines)
that rare 0.001% for me consists of things like the ransac family of meta-algorithms, mean-shift tracking, markov random fields, quadratic correlation filters, and support vector machines.
the latter. the former would require, amongst other things, access to the source code (as required by the original critterdings license) and a lot of noise coming from the biological disciplines re: computationally tractable, useful models for the various signaling pathways involved in hallucinogen use.
exactly, although i suspect that the right answer depends on the kind of person you are.
for me, very few things piss me off more quickly than getting a request to stay late to finish something for a deadline without even a hint of an offer of help from my management. this usually means i turn into the bad guy asking my team to work extra hours to deal with the most recent crisis caused by one of the other teams on our project (conveniently located elsewhere in the country and impossible to contact after 4pm eastern) screwing up.
If I ever meet a person with DeVry / ITT / etc. "credentials" who has done any of the following:
(a) designed fully decentralized, distributed, scalable, robust, real-time systems and successfully implemented and deployed said systems in the real world (b) built a compiler from the tokenizer up and understands every step of how code gets turned into bits and how those bits get executed on modern hardware (c) had an opportunity to use Tarjan's disjoint union / find algorithms and can explain where those data structures / algorithms are appropriate
I'd be interested in hiring him/her. The problem is that I have yet to meet such a person, because DeVry / ITT / etc. are degree mills whose sole purpose is to get as many people to cross the lowest possible bar that could pass accreditation -- i.e. turn a profit. As a consequence, the DeVry / ITT / etc. grads that I've had the "pleasure" of working with all have very narrow and shallow areas of competency and essentially zero ability to work outside those areas. The benefit of a four year degree is that in spite of all the fluff:
(a) you have a far better opportunity to actually cover the full breadth of theory (b) there is enough time to mature enough intellectually to start to grok the zen nature of the theory (c) you can't really choose between theory and practice; you have to demonstrate a degree of proficiency in both
it's not actually $370mil that gets spent on labor.
step 1: pull out overhead and profit. i'll be generous and estimate at 150% (this is probably *way* low). now you're down to 987 engineers for a year @ 150k per engineer per year step 2: pull out irrelevant direct charges (project management, accounting, etc.). assuming this explains 10% of billing (again, quite generous), you're now left with 888 engineers. etc.
it's pretty simple bud: if you think that databases or web development qualifies as a specialized comp. sci. area then you have either been mislead or are plain ignorant. more importantly, you should know that grad school is, generally, an extremely bad plan unless you're the peculiar kind of person that is really serious about your particular field. grad school will be _HELL_ if you don't love what you're doing. and to be honest, i don't think you love what you're doing.
i'd suggest you start exploring other options, because i'm afraid you've already lost this battle.
i'd wager that you suffer from some combination of:
1) confusing being a bastard with having a spine. user can't follow policy? kick them off the network. they want back on? get their boss to put it in writing and then sandbox the snot out of them. 2) being hamstrung by management (not backing you in disputes over policy, not giving you adequate resources) 3) being hamstrung by yourself (not proactively seeking out management's help when you need someone to back you on policy, give you resources; not hiring or otherwise outsourcing responsibility for desktop maintenance) 4) failure to manage expectations across the board (likely due to a failure to communicate)
if you suffer from #2, i'm afraid you're done at your current place of employment, same for #4. and while it is possible that #1 and #3, with time and the appropriate resources + backing from management, can be fixed, i wouldn't hold my breath.
... let me tell you that going from a company of 30 to a company of 140,030 is still quite a shock, and the purchase went through nearly 18 months ago.
if you decide to go down this path, make sure that: 1) you have definite set dates for _EVERY_ part of the transition, _especially_ for 401(k)s, health insurance, etc. these dates must be part of the terms of the contract with seriously stiff penalties. 2) take a long, hard look at all your groups' bumps and warts. if you're like my group, you have several excellent tech leads and no project managers. make sure that your potential purchaser can either fix or drastically improve all of your failings.
there's a lot more, but for me the biggest items are those 2.
the obvious reason: actually getting to take off fridays off is an iffy proposition, at least in my organization. i objected to it when it was implemented nearly 18 months ago as a sneaky, underhanded way to squeeze extra unpaid overtime out of employees and i feel even more strongly about that now than i did back then. i haven't had an off friday for the past 3 months and it seems increasingly unlikely that i'm going to get to take those fridays off until i get through a march delivery. obviously, your mileage will vary; however, unless your organization is serious about off fridays being sacred (mine, unfortunately, is not --- they expect you to be in the office on those fridays if there's even the slightest business need), expect to lose them quite frequently.
the non-obvious reasons: 1) trying to make up sick leave / personal absence gets to be really challenging. i find the incremental effort from 8 to 9 hours in a day not that bad, but 9 to 10 and beyond is really, really difficult (at least if my goal is to be actually productive as opposed to a warm body).
2) scheduling with clients / customers / team mates that are not on 9/80 gets to be more complicated, especially if you have multiple stakeholders whose off fridays are out of phase.
3) receiving shipments of parts / software / hardware / etc. on time can be difficult unless you have a dedicated receiving department working throughout the week.
4) depending on how you do time cards (assuming you do), correctly transcribing time can be a challenge. (you need two fridays per week)
if it were up to me, i would teach a first course in computer science using only pencils (maybe pens for the foolhardy) and paper. i say that as someone who has t.a.'d a lot of programming classes.
the issue, at least as far as i've observed, is that until a student has a solid ability to start decomposing a problem using top-down and bottom-up approaches, trying to teach them any kinds of programming language or algorithms is pointless. it's like having a carburetor and no car.
i would suggest that c.s. instruction, especially at the early phases, should aim to make students spend a lot of time asking questions like: "what information do i need to solve this problem?", "what is the easiest useful thing i can do to help solve this problem?", "what's missing from my solution?", "is it easier to break this step down more or just do it right here?", "how can i join X and Y to do Z?", etc. once you get students asking those questions, picking up programming languages is a lot easier: they know what they want to do, all they need to focus on is how.
hence computer science taught at a university as opposed to programming taught at a trade school. there is a reason that physicists receive very different training from mechanical engineers who receive very different training from mechanics. the world has a place for all these people. i, however, have zero desire to be a mechanic.
as someone on the other side (us citizen working on ITAR restricted technologies / programs that _require_ collaborating with foreign nationals), i can vouch for just how massive a pain-in-the-ass ITAR is:
i can't talk to foreign national colleagues about anything other than the weather. i can't deal with foreign vendors. i can't buy parts from foreign companies unless we have import licenses on file. i can't get support without first having to filter all questions through a company export officer. i can't ship equipment for repair if it has to leave the us (novatel, i'm looking at *you*) i can't share interface definitions or software process documents without an export license.
really, the restrictions verge on the absurd, especially when you consider that the papers describing most of the interesting technologies that i work on are published in international journals and freely available, often themselves as a result of gov't funded research.
and are you a us citizen? if the answer to both is "yes", then you should take a look at the various major defense contractors (lockheed martin, boeing, raytheon, northrop grumman, etc.) i know lockheed has about 50 odd entry level positions in denver open last i looked (two or so weeks ago). the large programs really prefer associate engineers and engineers because they tend to be relatively cheap compared to the staff and senior staff engineers.
1) go buy code complete. read it a chapter a week. when you are done, reread it. if your understanding of the book has not changed completely, you need to go find a new career.
2) learn discipline now. code complete has some excellent examples (e.g. declaring variables only as you need them and initialize them immediately, put constants on the left hand sides of logical tests, etc.) and your coding standards should provide other guidance.
3) take dijkstra's words to heart: "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague." corollary: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." (kernigan)
4) get in the habit of maintaining engineering notebooks. over time you'll figure out how to keep useful notes and those notebooks will be worth their weight (or more!) in gold.
5) go find a senior dev that you have a solid personal relationship with and see if you can establish an informal mentor/mentee relationship.
6) ask questions. lots of them. keep on asking until you're satisfied with the answer.
7) understand that any task that requires more than 2 minutes worth of programming merits at least 10 minutes worth of putting a plan together / drawing pictures / planning and at least 30 minutes worth of testing (ideally by adding to an existing automated test suite, hint hint...)
But I can code just as well without even having heard of UML, as I could knowing it. i don't really believe that, at least not in the general case.
understanding a single class, or even a small package of classes isn't too big a deal without tool support. so, to the degree that a person never has to understand large amounts of interesting code (say, 25+ nontrivial classes in 1000+ threads interacting asynchronously), i'll believe that a notation like uml won't necessarily have a significant impact.
on the other hand, the moment interesting amounts of sufficiently complex code get involved, my experience has been that peoples' ability to digest and understand enough of it that they can be useful drops off exponentially. in that case, a visual notation like uml becomes a really powerful tool to aid understanding.
1, 3, and 5 are redundant ("oh noes! it's big!"). they're also pretty weak. IEEE1394 is a pretty big standard (especially by the time you factor in all the standards it's built on). ditto USB, various flavors of PCI, XML, IEEE 802.3*, IEEE 802.11*, etc. does that mean we shouldn't use those standards? or does it mean that the specifications are as complex as the processes / protocols / etc. that they define?
4, 6, 7, 13 are also redundant and a misunderstanding of what uml is meant to do, which is *model* (see, right there in the middle of its name), as opposed to what the people writing the marketing blurbs for the tools are pedalling. this is a gripe with tool vendors' marketing departments and not uml.
an experienced uml user would know that 11 is pretty much total crap --- uml tools have supported round trip engineering (i.e. model a bit, regen code, mess with code, update model and the changes in the code magically appear) for quite a while now.
12 really irks me. if you are a software engineering professional, your job is to apply a process that starts with requirements, refines them, then converts them into detailed design specifications, implements that design specification, and finally validates and verifies that the implementation is correct. if you bemoan the use of process, you have no business working in software or anything even vaguely related to engineering.
8 i find particularly disingenuous. matlab costs just sy of $3k per license, and additional toolkits run $1-5k per license as well, for a "typical" per seat license cost between $7 and 15k. cad packages also cost thousands of dollars per seat. all that means is that the tool needs to make most people marginally more productive to break even.
2 is ridiculous. oh no! people want to make money!
in case you're keeping score, 5 of 13 claims are utter crap, with 7 of the 8 remaining claims being highly redundant. half of those claims relate to complexity, and half those claims relate to marketing hype. that leaves one gripe (#9) that i tend to mildly agree with. so really 4 claims, and a whole lot of ignorance and inexperience.
your argument is pretty weak. because MRI's require a certain level of training and tools to understand and / or use, it's essentially the same as an MRI not existing? does the same apply to FEM, CFD, circuit simulator, or any other package that requires more training than office to use effectively?
the short answer to your question is: both. developers should keep up with their tools, the same way i expect doctors to keep up with new treatments and diseases, lawyers to keep up with recent decisions and new legislation, accountants to stay abreast of IRS audit requirements, etc. continuing education is a pretty standard part of any profession.
congratulations. this was obvious back before 1998 and certainly a long time before then. unfortunately, the "article" was written by someone who doesn't really grok uml. specious claims include: "No solution for multi-tasking and communication between tasks" which is false as of UML 1.4 (active v. passive classes, message diagrams)" and "No dependency between use cases" which is also false --- add an association with the > stereotype.
there are some legitimate gripes (i think they could have chosen more distinct shapes), but most of that list is a laundry list of bitching and moaning by a person who hasn't actually developed the requisite level of proficiency with uml to actually understand how to use it well.
this is probably more a feature than a bug --- those instruments are rated by multiple agencies, each of which use their own risk evaluation methodologies and software. i find it highly unlikely that s&p would make mistakes, independently, that would cause it to give the same junk paper the same AAA rating that moody's gave.
you would think, but given the creative lawyering and flagrant corporate abuse of legal systems across the world, you might well be wrong. if there's anything to be learned from the legal system(s) in the u.s., it is that it doesn't cost much to write laws to your advantage.
Slashdot Mirror
give me $30k in consulting fees and i'll tell you who to hire.
here's the problem: every day, i make pretty heavy use of machine learning and the other bits and pieces that collectively get referred to as artificial intelligence. as a consequence, i deal with a very large number of fools who are each convinced that their $ALGORITHM is an earth shattering new paradigm for $TASK and clearly is the best thing evar. so you start reading and you realize that in 99.999% of cases, you're staring at something that is some combination of:
a) based on a fundamentally broken assumptions (usually never even stated)
b) bad analogies that obfuscate the fact that wheels are being re-invented (usually poorly)
c) narrowly defined special case
d) broken (provably non-optimal optimization routines)
that rare 0.001% for me consists of things like the ransac family of meta-algorithms, mean-shift tracking, markov random fields, quadratic correlation filters, and support vector machines.
the latter. the former would require, amongst other things, access to the source code (as required by the original critterdings license) and a lot of noise coming from the biological disciplines re: computationally tractable, useful models for the various signaling pathways involved in hallucinogen use.
exactly, although i suspect that the right answer depends on the kind of person you are.
for me, very few things piss me off more quickly than getting a request to stay late to finish something for a deadline without even a hint of an offer of help from my management. this usually means i turn into the bad guy asking my team to work extra hours to deal with the most recent crisis caused by one of the other teams on our project (conveniently located elsewhere in the country and impossible to contact after 4pm eastern) screwing up.
Quick: who are Robert Tarjan, Edsgar Dijkstra, Robert Floyd and Stephen Warshall and why would you care about their work?
Which brings me to my point: if you don't know what you're looking for, all the references in the world are essentially useless to you.
If I ever meet a person with DeVry / ITT / etc. "credentials" who has done any of the following:
(a) designed fully decentralized, distributed, scalable, robust, real-time systems and successfully implemented and deployed said systems in the real world
(b) built a compiler from the tokenizer up and understands every step of how code gets turned into bits and how those bits get executed on modern hardware
(c) had an opportunity to use Tarjan's disjoint union / find algorithms and can explain where those data structures / algorithms are appropriate
I'd be interested in hiring him/her. The problem is that I have yet to meet such a person, because DeVry / ITT / etc. are degree mills whose sole purpose is to get as many people to cross the lowest possible bar that could pass accreditation -- i.e. turn a profit. As a consequence, the DeVry / ITT / etc. grads that I've had the "pleasure" of working with all have very narrow and shallow areas of competency and essentially zero ability to work outside those areas. The benefit of a four year degree is that in spite of all the fluff:
(a) you have a far better opportunity to actually cover the full breadth of theory
(b) there is enough time to mature enough intellectually to start to grok the zen nature of the theory
(c) you can't really choose between theory and practice; you have to demonstrate a degree of proficiency in both
it's not actually $370mil that gets spent on labor.
step 1: pull out overhead and profit. i'll be generous and estimate at 150% (this is probably *way* low). now you're down to 987 engineers for a year @ 150k per engineer per year
step 2: pull out irrelevant direct charges (project management, accounting, etc.). assuming this explains 10% of billing (again, quite generous), you're now left with 888 engineers.
etc.
it's pretty simple bud: if you think that databases or web development qualifies as a specialized comp. sci. area then you have either been mislead or are plain ignorant. more importantly, you should know that grad school is, generally, an extremely bad plan unless you're the peculiar kind of person that is really serious about your particular field. grad school will be _HELL_ if you don't love what you're doing. and to be honest, i don't think you love what you're doing.
i'd suggest you start exploring other options, because i'm afraid you've already lost this battle.
i'd wager that you suffer from some combination of:
1) confusing being a bastard with having a spine. user can't follow policy? kick them off the network. they want back on? get their boss to put it in writing and then sandbox the snot out of them.
2) being hamstrung by management (not backing you in disputes over policy, not giving you adequate resources)
3) being hamstrung by yourself (not proactively seeking out management's help when you need someone to back you on policy, give you resources; not hiring or otherwise outsourcing responsibility for desktop maintenance)
4) failure to manage expectations across the board (likely due to a failure to communicate)
if you suffer from #2, i'm afraid you're done at your current place of employment, same for #4. and while it is possible that #1 and #3, with time and the appropriate resources + backing from management, can be fixed, i wouldn't hold my breath.
... let me tell you that going from a company of 30 to a company of 140,030 is still quite a shock, and the purchase went through nearly 18 months ago.
if you decide to go down this path, make sure that:
1) you have definite set dates for _EVERY_ part of the transition, _especially_ for 401(k)s, health insurance, etc. these dates must be part of the terms of the contract with seriously stiff penalties.
2) take a long, hard look at all your groups' bumps and warts. if you're like my group, you have several excellent tech leads and no project managers. make sure that your potential purchaser can either fix or drastically improve all of your failings.
there's a lot more, but for me the biggest items are those 2.
DISCLAIMER: I'm in the no-man's-land 'twixt being young-and-bright and old-and-wise. :-)
so you're in your 30's, depressed, and trying to figure out what you did with the last 10-15 years of your life?
(i'm not sure what it means that i'm 28 and going through the same thing...)
the obvious reason:
actually getting to take off fridays off is an iffy proposition, at least in my organization. i objected to it when it was implemented nearly 18 months ago as a sneaky, underhanded way to squeeze extra unpaid overtime out of employees and i feel even more strongly about that now than i did back then. i haven't had an off friday for the past 3 months and it seems increasingly unlikely that i'm going to get to take those fridays off until i get through a march delivery. obviously, your mileage will vary; however, unless your organization is serious about off fridays being sacred (mine, unfortunately, is not --- they expect you to be in the office on those fridays if there's even the slightest business need), expect to lose them quite frequently.
the non-obvious reasons:
1) trying to make up sick leave / personal absence gets to be really challenging. i find the incremental effort from 8 to 9 hours in a day not that bad, but 9 to 10 and beyond is really, really difficult (at least if my goal is to be actually productive as opposed to a warm body).
2) scheduling with clients / customers / team mates that are not on 9/80 gets to be more complicated, especially if you have multiple stakeholders whose off fridays are out of phase.
3) receiving shipments of parts / software / hardware / etc. on time can be difficult unless you have a dedicated receiving department working throughout the week.
4) depending on how you do time cards (assuming you do), correctly transcribing time can be a challenge. (you need two fridays per week)
if it were up to me, i would teach a first course in computer science using only pencils (maybe pens for the foolhardy) and paper. i say that as someone who has t.a.'d a lot of programming classes.
the issue, at least as far as i've observed, is that until a student has a solid ability to start decomposing a problem using top-down and bottom-up approaches, trying to teach them any kinds of programming language or algorithms is pointless. it's like having a carburetor and no car.
i would suggest that c.s. instruction, especially at the early phases, should aim to make students spend a lot of time asking questions like: "what information do i need to solve this problem?", "what is the easiest useful thing i can do to help solve this problem?", "what's missing from my solution?", "is it easier to break this step down more or just do it right here?", "how can i join X and Y to do Z?", etc. once you get students asking those questions, picking up programming languages is a lot easier: they know what they want to do, all they need to focus on is how.
it's called systems biology.
hence computer science taught at a university as opposed to programming taught at a trade school. there is a reason that physicists receive very different training from mechanical engineers who receive very different training from mechanics. the world has a place for all these people. i, however, have zero desire to be a mechanic.
as someone on the other side (us citizen working on ITAR restricted technologies / programs that _require_ collaborating with foreign nationals), i can vouch for just how massive a pain-in-the-ass ITAR is:
i can't talk to foreign national colleagues about anything other than the weather.
i can't deal with foreign vendors.
i can't buy parts from foreign companies unless we have import licenses on file.
i can't get support without first having to filter all questions through a company export officer.
i can't ship equipment for repair if it has to leave the us (novatel, i'm looking at *you*)
i can't share interface definitions or software process documents without an export license.
really, the restrictions verge on the absurd, especially when you consider that the papers describing most of the interesting technologies that i work on are published in international journals and freely available, often themselves as a result of gov't funded research.
and are you a us citizen? if the answer to both is "yes", then you should take a look at the various major defense contractors (lockheed martin, boeing, raytheon, northrop grumman, etc.) i know lockheed has about 50 odd entry level positions in denver open last i looked (two or so weeks ago). the large programs really prefer associate engineers and engineers because they tend to be relatively cheap compared to the staff and senior staff engineers.
1) go buy code complete. read it a chapter a week. when you are done, reread it. if your understanding of the book has not changed completely, you need to go find a new career.
2) learn discipline now. code complete has some excellent examples (e.g. declaring variables only as you need them and initialize them immediately, put constants on the left hand sides of logical tests, etc.) and your coding standards should provide other guidance.
3) take dijkstra's words to heart: "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague." corollary: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." (kernigan)
4) get in the habit of maintaining engineering notebooks. over time you'll figure out how to keep useful notes and those notebooks will be worth their weight (or more!) in gold.
5) go find a senior dev that you have a solid personal relationship with and see if you can establish an informal mentor/mentee relationship.
6) ask questions. lots of them. keep on asking until you're satisfied with the answer.
7) understand that any task that requires more than 2 minutes worth of programming merits at least 10 minutes worth of putting a plan together / drawing pictures / planning and at least 30 minutes worth of testing (ideally by adding to an existing automated test suite, hint hint...)
understanding a single class, or even a small package of classes isn't too big a deal without tool support. so, to the degree that a person never has to understand large amounts of interesting code (say, 25+ nontrivial classes in 1000+ threads interacting asynchronously), i'll believe that a notation like uml won't necessarily have a significant impact.
on the other hand, the moment interesting amounts of sufficiently complex code get involved, my experience has been that peoples' ability to digest and understand enough of it that they can be useful drops off exponentially. in that case, a visual notation like uml becomes a really powerful tool to aid understanding.
12? really?
1, 3, and 5 are redundant ("oh noes! it's big!"). they're also pretty weak. IEEE1394 is a pretty big standard (especially by the time you factor in all the standards it's built on). ditto USB, various flavors of PCI, XML, IEEE 802.3*, IEEE 802.11*, etc. does that mean we shouldn't use those standards? or does it mean that the specifications are as complex as the processes / protocols / etc. that they define?
4, 6, 7, 13 are also redundant and a misunderstanding of what uml is meant to do, which is *model* (see, right there in the middle of its name), as opposed to what the people writing the marketing blurbs for the tools are pedalling. this is a gripe with tool vendors' marketing departments and not uml.
an experienced uml user would know that 11 is pretty much total crap --- uml tools have supported round trip engineering (i.e. model a bit, regen code, mess with code, update model and the changes in the code magically appear) for quite a while now.
12 really irks me. if you are a software engineering professional, your job is to apply a process that starts with requirements, refines them, then converts them into detailed design specifications, implements that design specification, and finally validates and verifies that the implementation is correct. if you bemoan the use of process, you have no business working in software or anything even vaguely related to engineering.
8 i find particularly disingenuous. matlab costs just sy of $3k per license, and additional toolkits run $1-5k per license as well, for a "typical" per seat license cost between $7 and 15k. cad packages also cost thousands of dollars per seat. all that means is that the tool needs to make most people marginally more productive to break even.
2 is ridiculous. oh no! people want to make money!
in case you're keeping score, 5 of 13 claims are utter crap, with 7 of the 8 remaining claims being highly redundant. half of those claims relate to complexity, and half those claims relate to marketing hype. that leaves one gripe (#9) that i tend to mildly agree with. so really 4 claims, and a whole lot of ignorance and inexperience.
your argument is pretty weak. because MRI's require a certain level of training and tools to understand and / or use, it's essentially the same as an MRI not existing? does the same apply to FEM, CFD, circuit simulator, or any other package that requires more training than office to use effectively?
the short answer to your question is: both. developers should keep up with their tools, the same way i expect doctors to keep up with new treatments and diseases, lawyers to keep up with recent decisions and new legislation, accountants to stay abreast of IRS audit requirements, etc. continuing education is a pretty standard part of any profession.
uml as practiced by uml fetishists is a bad idea.
congratulations. this was obvious back before 1998 and certainly a long time before then. unfortunately, the "article" was written by someone who doesn't really grok uml. specious claims include: "No solution for multi-tasking and communication between tasks" which is false as of UML 1.4 (active v. passive classes, message diagrams)" and "No dependency between use cases" which is also false --- add an association with the > stereotype.
there are some legitimate gripes (i think they could have chosen more distinct shapes), but most of that list is a laundry list of bitching and moaning by a person who hasn't actually developed the requisite level of proficiency with uml to actually understand how to use it well.
this is probably more a feature than a bug --- those instruments are rated by multiple agencies, each of which use their own risk evaluation methodologies and software. i find it highly unlikely that s&p would make mistakes, independently, that would cause it to give the same junk paper the same AAA rating that moody's gave.
i would gladly trade you my dell 20" lcd for a reasonable 20-24" wide screen. unfortunately "my" dell isn't mine to give away :-/
you would think, but given the creative lawyering and flagrant corporate abuse of legal systems across the world, you might well be wrong. if there's anything to be learned from the legal system(s) in the u.s., it is that it doesn't cost much to write laws to your advantage.