That is because he provided HARD EVIDENCE. Power-point slides that explain the scope of the program. [...] The slides clearly show what is currently existing within the scope of the system and what is forecast for the future.
So, apparently some things are not yet adding up about the conclusions drawn from those PowerPoint slides: http://www.rants.org/2013/06/11/epic_botch_of_prism_story/ https://medium.com/prism-truth/82a1791c94d3
I don't know. I assumed they were already doing this (almost all, slightly more, or slightly less) for at least the past ten years. I'm not keen about the civilization necessarily requiring a real, actual surveillance state, if that's what we indeed have. Finally, I don't know what to think about Snowden, and don't really care to jump to conclusions about that, either.
Here's some more I had been looking at: http://www.dailykos.com/story/2013/06/10/1214540/-Five-stages?showAll=yes http://cryptome.org/
IMO the thing which crippled large Smalltalk projects was the corporate IT market embracing programming technologies which looked more like C. You had to fight hard to make Smalltalk code look like a procedural language, which a larger body of programmers were already used to. Java, C++, and C# look more like C, so I guess they have that going for them.
Smalltalk is a strongly-typed, late-binding language. Smalltalk's Object>>#doesNotUnderstand behavior is a hindrance for production-quality code only to the extent that your programmers are unwilling or unable to read and use someone else's API. Oh, and maybe your system design should not suck, no matter what programming technology is involved.
I worked for years as a Smalltalk programmer on big, corporate IT systems involving hundreds of programmers and handling hundreds of millions of $$$ per day in production, but corporate IT has had a mood swing and now our systems mostly use the early-binding programming technologies. I like being gainfully employed, but am not persuaded the tradeoffs of the extra code, convoluted syntax constructions, and tool paradigms actually represent any improvements. And finally, believe it or not, but the less senior programmers apparently have difficulty reading and understanding the code (even with its early-binding features) written by far more experienced programmers than myself, which in turn results in numerous and varied production defects. Who would have thunk it, eh?
just VB subroutines that modify global variables [...] And by the way, the functions aren't cohesive, each one is 100's of lines
Searching the web on 'Junit VB' you should be able to find test harness freeware.
If there's the possibility of modifying the code organization that would help out a lot, obviously, because then you could make smaller functions doing more sharply defined things and therefore presumably easier to test.
If not perhaps assume you can't test more of the existing code except at a high-level, or perhaps investigate what libraries are available for asserts/tracing within VB code. In combination with asserts/tracing maybe the test harness would provide different sets of test data/actions and exercise different paths through the big blog of code, thereby demonstrating correct results, API limitations, error/exception handling, etc.
I don't mind Bush at all, only his administration's policies. (Well, I could do without his middle finger salute video clip.)
I find it very doubtful they will be any more "uniters instead of dividers" this go-round than their empty promise to do so the first campaign.
I voted for Kerry, however I'm not surprised Bush won, only because I believe so many of my fellow Americans are either too naive to vote or still a little bit thick-headed after only four years. Oh well, time will tell, right?
Well maybe. Does "anything else" imply that capital is likewise a commodity? Or not? It sounds like you're ready at the drop of a hat to start making excuses for capital bullying labor when the facts don't match some idealized pursuit of economic efficiency and "free trade." My point would be that the facts are a lot closer to a zero sum game than you're willing to admit.
Conversely, a simple thought experiment will tell you the ultimate booster to employment - ban all trade! [...]
It's a slippery slope you're offering.
I live in the South. If the gains seen from the tax-incentive driven influx of "autobahn" manufacturing work in the weak labor law environs of the South is anything more than very modest, I'd like to hear more about it... much more so than dopey false choice comments about "utopia this" and "zero sum that." From the rationales presented, there's NO GOOD REASON not to outsource a lot of other things, including corporate owners, economists, social scientists, all politicians (they'll give us PDAs to input polling data), etc., etc. Oh, and I know... it's somehow a sign of a great goodness pursuing economic efficiency that the auto plant work disintegrated in the North and somehow modestly reappeared in the South, right? Instead of perhaps 'waste', 'stupidity', etc., etc. ?
I've used XP (pieces, not the full ball of wax) in two very big, important projects and we've been successful. We didn't use all of XP because the managers, project sponsors, and some of the techs weren't comfortable moving to full-on XP. Both systems are in production.
I haven't read the book and have no interest in reading the book. I think the book's authors and the reviewer are likely nice guys however I was put off by the 'attack mode' which rings of (1) character assassination and (2) someone else's methodology (Not Invented Here).
Yes, in the real world of programming projects some head tech/manager dude usually is laying down the law about methodologies, technological direction, design techniques, etc. Yes, I'd trust the luminary/author who came up with those pop-Zen sayings to design and implement a 10000 tps system, shocking as that might seem after this review. Yes, getting buy-in from management to do anything in a project is extremely important.
"Foisting" XP or anything else on unwilling or incredulous managers/workers won't succeed. That seems reasonable enough. Assuming it's all bad because some goof tells you so seems kind of overboard as well.
Actually I think it's suggested the opposite is a typical self-fulfilling condition.
Blame the process or methodology, no matter how 'light-weight' their use of process methodology was.
For comparison, a hypothetical project decides to use RUP (Rational Unified Process) for their methodology... their goal is to gain the benefits of RUP. The project starts off with grand methodology plans, e.g. dev iterations, analysis and design phases, lots of documentatation and artifacts. About 10% of the way in they start having problems and at 20% of the plan they figure out they'll over-shoot their allotted resources by at least 100%, e.g. dev project to be completed sometime beyond the forseeable future. So they drop the methodology and try something (anything) else. OK, given they failed while using RUP, are you ready to be condemning of RUP now?
If XP practices don't appeal to you in part or as a package, that's quite acceptable but not much of a rationale to spout off about 'it doesn't work'.
>>>(an aspect which seems to be proving almost heretical among some XP advocates).
From the review I gather the reviewer really likes to call XP proponents 'zealots', doesn't like pair programming, and really likes the book... all for fairly vague or undisclosed reasons. I read the build-up of implied negative things about XP as a Straw Man fallacy.
Who cares if XP might not be as rigid or lacking as implied by the review? Does it matter if innumerable IT depts and s/w houses absolutely treasure the old ways of scheduling, implementing, and maintaining software? And that at least some of them are at least marginally successful? Immaterial! Can programmers ever figure out how to program on their own, or in groups, or in the project/company of the PHB? That's indeed a tough one, and it's obviously necessary to combat with some arbitrary, unquestioned ideology.
Slashdot Mirror
That is because he provided HARD EVIDENCE. Power-point slides that explain the scope of the program. [...] The slides clearly show what is currently existing within the scope of the system and what is forecast for the future.
So, apparently some things are not yet adding up about the conclusions drawn from those PowerPoint slides:
http://www.rants.org/2013/06/11/epic_botch_of_prism_story/
https://medium.com/prism-truth/82a1791c94d3
I don't know. I assumed they were already doing this (almost all, slightly more, or slightly less) for at least the past ten years. I'm not keen about the civilization necessarily requiring a real, actual surveillance state, if that's what we indeed have. Finally, I don't know what to think about Snowden, and don't really care to jump to conclusions about that, either.
Here's some more I had been looking at:
http://www.dailykos.com/story/2013/06/10/1214540/-Five-stages?showAll=yes
http://cryptome.org/
IMO the thing which crippled large Smalltalk projects was the corporate IT market embracing programming technologies which looked more like C. You had to fight hard to make Smalltalk code look like a procedural language, which a larger body of programmers were already used to. Java, C++, and C# look more like C, so I guess they have that going for them.
Smalltalk is a strongly-typed, late-binding language. Smalltalk's Object>>#doesNotUnderstand behavior is a hindrance for production-quality code only to the extent that your programmers are unwilling or unable to read and use someone else's API. Oh, and maybe your system design should not suck, no matter what programming technology is involved.
I worked for years as a Smalltalk programmer on big, corporate IT systems involving hundreds of programmers and handling hundreds of millions of $$$ per day in production, but corporate IT has had a mood swing and now our systems mostly use the early-binding programming technologies. I like being gainfully employed, but am not persuaded the tradeoffs of the extra code, convoluted syntax constructions, and tool paradigms actually represent any improvements. And finally, believe it or not, but the less senior programmers apparently have difficulty reading and understanding the code (even with its early-binding features) written by far more experienced programmers than myself, which in turn results in numerous and varied production defects. Who would have thunk it, eh?
Silkroad Online is free too. They have premium in-game items (100% more exp, item repair, etc.) that you can pay for, but there's no subscription.
err... big BLOB of code
Searching the web on 'Junit VB' you should be able to find test harness freeware.
If there's the possibility of modifying the code organization that would help out a lot, obviously, because then you could make smaller functions doing more sharply defined things and therefore presumably easier to test.
If not perhaps assume you can't test more of the existing code except at a high-level, or perhaps investigate what libraries are available for asserts/tracing within VB code. In combination with asserts/tracing maybe the test harness would provide different sets of test data/actions and exercise different paths through the big blog of code, thereby demonstrating correct results, API limitations, error/exception handling, etc.
Good luck.
Smalltalk is wonderful if you give it a chance. You're right in saying that it's not "C-like."
I voted for Kerry, however I'm not surprised Bush won, only because I believe so many of my fellow Americans are either too naive to vote or still a little bit thick-headed after only four years. Oh well, time will tell, right?
Well maybe. Does "anything else" imply that capital is likewise a commodity? Or not? It sounds like you're ready at the drop of a hat to start making excuses for capital bullying labor when the facts don't match some idealized pursuit of economic efficiency and "free trade." My point would be that the facts are a lot closer to a zero sum game than you're willing to admit.
Conversely, a simple thought experiment will tell you the ultimate booster to employment - ban all trade! [...]
It's a slippery slope you're offering.
I live in the South. If the gains seen from the tax-incentive driven influx of "autobahn" manufacturing work in the weak labor law environs of the South is anything more than very modest, I'd like to hear more about it... much more so than dopey false choice comments about "utopia this" and "zero sum that." From the rationales presented, there's NO GOOD REASON not to outsource a lot of other things, including corporate owners, economists, social scientists, all politicians (they'll give us PDAs to input polling data), etc., etc. Oh, and I know... it's somehow a sign of a great goodness pursuing economic efficiency that the auto plant work disintegrated in the North and somehow modestly reappeared in the South, right? Instead of perhaps 'waste', 'stupidity', etc., etc. ?
non-linky address:
http://minnow.cc.gatech.edu/squeak/5
*sigh*
Here's a good sample of what Smalltalk's about, from the Squeak site. (I hope that link is the right format.)
I've used XP (pieces, not the full ball of wax) in two very big, important projects and we've been successful. We didn't use all of XP because the managers, project sponsors, and some of the techs weren't comfortable moving to full-on XP. Both systems are in production.
I haven't read the book and have no interest in reading the book. I think the book's authors and the reviewer are likely nice guys however I was put off by the 'attack mode' which rings of (1) character assassination and (2) someone else's methodology (Not Invented Here).
Yes, in the real world of programming projects some head tech/manager dude usually is laying down the law about methodologies, technological direction, design techniques, etc. Yes, I'd trust the luminary/author who came up with those pop-Zen sayings to design and implement a 10000 tps system, shocking as that might seem after this review. Yes, getting buy-in from management to do anything in a project is extremely important.
"Foisting" XP or anything else on unwilling or incredulous managers/workers won't succeed. That seems reasonable enough. Assuming it's all bad because some goof tells you so seems kind of overboard as well.
Blame the process or methodology, no matter how 'light-weight' their use of process methodology was.
For comparison, a hypothetical project decides to use RUP (Rational Unified Process) for their methodology... their goal is to gain the benefits of RUP. The project starts off with grand methodology plans, e.g. dev iterations, analysis and design phases, lots of documentatation and artifacts. About 10% of the way in they start having problems and at 20% of the plan they figure out they'll over-shoot their allotted resources by at least 100%, e.g. dev project to be completed sometime beyond the forseeable future. So they drop the methodology and try something (anything) else. OK, given they failed while using RUP, are you ready to be condemning of RUP now?
If XP practices don't appeal to you in part or as a package, that's quite acceptable but not much of a rationale to spout off about 'it doesn't work'.
Isn't that a rather self-fulfilling condition?
Well, we could always hold out hope for examples.
>>>(an aspect which seems to be proving almost heretical among some XP advocates).
From the review I gather the reviewer really likes to call XP proponents 'zealots', doesn't like pair programming, and really likes the book... all for fairly vague or undisclosed reasons. I read the build-up of implied negative things about XP as a Straw Man fallacy.
Who cares if XP might not be as rigid or lacking as implied by the review? Does it matter if innumerable IT depts and s/w houses absolutely treasure the old ways of scheduling, implementing, and maintaining software? And that at least some of them are at least marginally successful? Immaterial! Can programmers ever figure out how to program on their own, or in groups, or in the project/company of the PHB? That's indeed a tough one, and it's obviously necessary to combat with some arbitrary, unquestioned ideology.