"Big deal."

Just trying to point the discussion in the right direction - toward facts, rather than inaccuracies and hearsay. That may not change anyone's overall assessment, but at least it provides a better basis for making such a judgement.

"Overall, they're a pernicious influence in society."

If you see them as the trend toward which every college should go, yes. On the other hand, they also provide educational opportunities to a lot of people ignored or sidelined by traditional colleges, and as an additional option - like community colleges are an additional option - I see value.

Perhaps the difference in our opinion is really that I don't view traditional universities in as positive a light, particularly for people who don't fit into the expected mold, so the standard by which I judge Phoenix is lower.

That's an interesting take. The University of Phoenix is actually accredited, by the North Central Association of Colleges and Schools, which in turn is recognized by the Department of Education and the Council for Higher Education Accreditation. Also, although I can't speak for UoP, the school I'm attending online offers recorded lectures (for aural learning and note-taking), discussion forums where the TA is active, opportunities to ask the professor questions live during class (naturally, this requires being online when the on-site class is being held) and plenty of homework to learn by doing.

I think you're also generally giving for-profit schools short shrift for little good reason; they don't spend (or seek) money based on football teams, or endowments, but are actively trying to sell the quality of pedagogy and student attention. From what little I've seen, they pay more attention to student feedback on teachers, and teachers aren't given free reign to treat students like crap just because they've done important research. That doesn't mean they're perfect, but - like community colleges - they have a place of value and importance in society.

So far I've done the traditional undergraduate degree, community college (actually after I got my Bachelor's), online classes, and yes a ton of learning on my own. They're all opportunities to learn and challenge yourself, with varying degrees and kinds of support infrastructure to encourage and help you. But they are definitely all different, and I think they do serve different purposes and subsets of the population.

This the essence of technical debt. Whether you're programming or deploying IT infrastructure, it's inescapable that sometimes you're going to have to include kludges to work around edge conditions, a vocal 1% of your users, or whatever. These kludges are eyesores, and fragile, but they're also as far as you could go with the time and budget you had.

Sometimes, accruing debt like this enhances your liquidity and ability to respond to change, so avoiding all kludges introduces other more obvious costs that slow you down and make you seem unresponsive to users or customers. But you can't just go on letting your debt grow all the time and not eventually come up technically bankrupt. Let it grow when you have to, but just as importantly make time to pay it down. A lot of this stuff can be paid down a little at a time, as you come across it a few months later. The pay-off if you're vigilant is that the next ridiculously urgent fix to that system can often be handled much more easily, without dipping down further... with patience and attention to maintaining this balance, you can reduce your technical debt and make the whole system hum.

The downside is that there isn't a quick fix when you find yourself deep in technical debt. You can't just spend all your time reducing it; your highest aspiration at that point should be maintaining the level of technical debt, rather than letting it grow, but it's generally been my experience that altering the curve of debt growth even a little can set you on the right path.

I skimmed it. One of the authors of MySQL I presume self-agrandising and taking credit for "saving" MySQL even though none of Oracle's promises are legally binding.

Those two sentences are completely contradictory. :-)

So, um, I take it you didn't read the article?

I use greylisting to reduce spam volume, and I whitelist outgoing mail servers for domains that a) have trouble with greylisting and b) publish SPF records. In other words, I use SPF given existing trust for a particular domain, but only if not relying on SPF causes problems. I thought I hadn't set up SPF records for my own (vanity) domains, but apparently I have... not that I particularly notice. It's just not a big deal.

My point isn't that Eve is a paragon of perfect architecture, it's that the system works. Geographic decomposition is not so flawed that e.g. it requires you to shard your game and set up server queues that ultimately piss people off.

I'm also not arguing that it's the only or best way to go, but it may very well be right for a particular game anyway.

Heh, no. I'm an MMOG server programmer, and I know a fair number of others, and a lot of us have backgrounds in distributed computing, with plenty spending time in academia before being lured into games. That game companies mostly hire people with game design degrees is a falsehood propagated by the institutions that offer those degrees. For one thing, there simply aren't enough people going through those schools to feed the industry's need for fresh meat; for another, the quality of programmers fresh out of any school is generally insufficient.

As for fundamental design flaws... eh. I've heard plenty of that kind of talk from (for example) Project Darkstar; it's easy to say that, it's a lot harder to actually do the research to understand all the options and the inherent flaws in each. Interestingly, even EVE Online - lauded for its one-world approach - uses geographic decomposition too, and it works just fine most of the time (and now they've got a system for dedicating special hardware to the corner cases).

I'll admit I have yet to hear anything positive about AMD/ATI's proprietary Linux driver, and it's been a while since anyone seemed to say nice things about the open source X.org driver either. Mine has integrated Intel graphics, and it works great; I can't play 3D games, but a) I program on this laptop, not game, and b) it runs Linux; how high should your hopes really be?

I previously had a T21, and yes, the keyboard was a little better - I guess your mileage may vary how much worse you think it is.

Also, I'm not sure if you noticed, but the original poster seemed pretty clear about the intent to run Windows: this may bother you, but that doesn't mean it's a problem for someone else. For myself, I never intended to run Windows (much less Vista) on this laptop, but it seemed like an acceptable tradeoff for the rest of the laptop.

I hadn't thought about alternative keyboard layouts; that sucks. It's definitely something to take into account. Similarly I can't say anything about Lenovo support; definitely something else to take into account.

I'm typing this response from a Thinkpad R500 :-)

Thinkpad docks are solid and have been around a long time, as have hotswap bays; some stuff like memory card readers are already present. Ubuntu works very well with both suspend and hibernate, many models support dual monitors via the dock (I think mine supports dual external monitors via the VGA and DisplayPort connectors, but haven't tested more than one external monitor; according to documentation two external monitors via the dock aren't supported), and the built-in LCD's resolution is extremely reasonable at 1680x1050.

And, of course, the keyboard is one of the best in the business (although I've heard vi users complain about the placement of the Esc key, getting proper spacing between F1 and Esc on a laptop isn't easy).

You know the magic has gone out when everything is reduced to a dichotomy between miniscule speed increases and enormous manageability increases. Of course the answer is obvious when it's phrased that way; of course it's a false dichotomy. At the very least, "readability" is in the eye of the beholder; performance, usually a bit more objective.

Perhaps that's why it's not glorious work anymore. :-P

...not that I ever looked at it as glorious stuff to begin with...

The ScrumMasters responsibility is to support the Organization to implement Scrum, thats all.

Right, of course. They are, as scrummasters say, involved in the project. They aren't fully committed the way the developers are, the ones who could lose their jobs if the project goes south.

And that's where the snake oil alarms go off; the scrummaster is someone that, according to scrum, is committed to the project in a visceral way. It's just not true, and it's dishonest right around the part where the scrum evangelist's job is on the line.

As for my own situation... I'm barely affected by scrum at all; supposedly we do it, but I can get my job done without caring what process is being used. I notice that we have more meetings now than when I wasn't in an organization doing scrum, and that interrupts my programming time; but overall it doesn't have much noticeable effect of any kind.

Scrum doesn't slow our project down, it doesn't accelerate it; it has zero effect. And that's the most damning thing - scrum doesn't matter. If it doesn't matter, why bother buying books, going through training, hiring more people... why spend all that money?

So then what's the product owner? How many different titles and concurrent positions need to be held by facilitators at once?

...if [test-driven development] is cut from Scrum, the project is doomed to fail...

I'm not going to argue against the value of test-driven development, but lack of test-driven development doesn't doom any project. Letting bugs get out the door can doom a project, but there are many-many ways of preventing that other than compulsive unit tests.

I have written a thesis about this problem - almost all project that "used agile development" methods and then failed, were trying to cut too many corners and modified a developed methodology breaking it in the process.

Yes, yes, if a project is agile but modified the Holy Process as defined in some book, and then failed, the failure is because they didn't follow the process. I covered this already. However, you make clear even in this one sentence that you aren't prepared to argue the opposite - that a survey of successful agile projects will show them using scrum (or XP, or...) precisely and without modification. The danger, as you put it, comes from cutting "too many" corners.

Simple question: do you agree that scrum masters should be fired if their project fails? After all, clearly the project wasn't following scrum properly, and it's the scrum master's job to make sure they are, so clearly the job was not done. In fact, the scrum master's failure caused the failure of the entire project! So, what should be done with the scrum master of a failed project?