"I will close this piece with a truth. "For all their sins, ads fuel much of the Web. Cut them out and you're strangling the diversity of online publishers â" I think users really want that."

I think this is exactly right, you are indeed strangling diversity of publishers, but the problem is, I'm not convinced it matters.

The problem as I see it, is that monetisation of information on the web via ads has simply led to a rush for psychological "you should click this and see what happens next" type bullshit, as well as incredibly inflammatory and often false headlines in a desperate rush to further increase ad revenue.

As such, whilst it may increase diversity of publishers, I do not believe it's a useful increase in diversity of publishers.

But you still have two problems there. Firstly, when the US has had cold winters, Europe has had mild winters, yet suffered the exact same problem. So your argument of a correlation of cold winters is also false - it only correlates if you take an arbitrary subset of known data.

Secondly, you argue that usage of neonicotinoids don't correlate - at best you can say they don't appear to correlate in the data you have seen, but plenty of studies show otherwise. For example, this study finds a correlation between the use of imidacloprid and cold winters, rather than varroa mite and cold winters:

http://www.hsph.harvard.edu/ne...

One could equally argue from this, and the European experience of mild winters, actually shows that neonicotinoids are in fact the common factor in the problem.

"What doesn't are vendor specific items like IE6, and if you were developing specifically for that, well, then you made a terrible choice, especially if it affected your entire application stack."

Oh stop showing you have no idea about software development. It's not about making a terrible choice, without being psychic one cannot make a better choice than supporting the two browsers that are used by the vast majority of the market. Not planning to support it when that's the status quo, and there's no obvious sign of impending change is utterly retarded. The fact that things did change is due to the unpredictable nature of technology.

"So apparently, the only thing that needed changing in your case was the GUI. If you knew squat about web development, that would have been a relatively minor thing to change, provided that you knew what you were doing in the first place. Building to IE6 indicates otherwise however."

The fact you think this shows how utterly out of your depth you are. The fact you believe you can blanket say that the UI is a small part of any project is utterly retarded, how do you know this? how do you know what the scope and scale of the project is? Stop talking about things you blatantly do not understand and cannot know about.

"No, what I need to be able to do is take technology today, as it exists, pick the proper components, even if they are alpha/beta, and ensure that my choices are kept up to date and do what they need to do, especially in the alpha/beta area. It's called tracking your dependencies, and it's not accomplished by tying yourself to maven central."

So in other words, use an agile process. Which is exactly what you're telling everyone not to do. Right.

"Have you worked in the real world? Generally a project is envisioned, then estimated and budgeted. This happens at the beginning of a project, because generally shareholders (public companies) don't like to spend 50M on a project (promised functionality) and not receive a working model."

Yes, and that's the point of Agile. It's designed to work in the real world where the only way you can truly estimate the amount of features you can implement for a specific cost is to actually do it. Thus, rather than pick a number and set of features out of thin air as with waterfall, you just set a budget, and keep rolling until you hit that budget, and what comes out is what is possible against that budget. If early on it looks like you're not even going to get close to the features you wanted for the budget, then you stop sprinting and fail early. This is far superior to failing late as with waterfall where you've blown your whole budget and ended up with something useless. Agile caters to change. That's the whole point.

Your description of GM and agile just further highlights that you don't know anything about agile. Agile doesn't demand that there are no communications between teams and stakeholders. The whole point of the job of stakeholders is that they're getting what they need, and if they're not working with other stakeholders to make it fit then what you're actually dealing with are inept project managers, which, guess what? also make waterfall projects fail on a regular basis. Retardation isn't limited to agile, nor is agile a magic cure for it.

"I'm describing the real world, how people try Agile, and how they and Agile fails. You can keep dreaming that it works"

Okay, I'll keep "dreaming" that it works, along with everyone that uses it to succesfully deliver projects, you know, like everyone from Google, to IBM, to Microsoft, to those government folks you falsely claimed only ever use waterfall:

http://www.cio.com/article/239...

People deliver with agile, the fact you claim they don't is evidence that you failed to implement it, or used the wrong tool for the job. That's not a defect with agile, that's a problem with your project leadership.

I've delivered large (multi-year projects) with both agile and waterfall, (and hybrids in between) using the right methodology for the task at hand. It can work well if you use it in the right place (e.g. UI development as you indirectly admitted above). If you've always failed with it, well, it sucks to be you. But I doubt you'll ever get it right if you blame the methodology rather than your processes. Plenty of companies, and plenty of massive projects do perfectly well with it though, so saying it doesn't work is patently false, and saying they do more than agile is a classic no true Scotsman fallacy.

"In essence, I practice neither process, but a project management style that is more dynamic that grew out of understanding waterfall's short-comings and agile lately claims some portions of as its own."

Most people do, and there's nothing wrong with that. But pretending agile doesn't ever work is as stupid as pretending waterfall never works. On the contrary, if you're building a bunch of pre-designed houses then waterfall works perfectly well because you know how long it takes you to build such a house when you've done it so many times before. Similarly, when you're doing something highly iterative in nature to get right, like UI work, then agile also works perfectly.

As an aside, I find it fascinating that all your examples seem to dodge software development and focus on things like cars, and government non-software projects. That, coupled with your other comments doesn't half make it look like you really do know fuck all about software development, especially as you seem to believe that trends in the technology world are reliably knowable a number of years ahead of time.

That's right, let it all out.

No really, you should go and get those blood pressure levels checked about now, continuing being wrong, getting all upset, and filling the discussion with your tears really is not healthy.

"You know what that's a sign of? Failure to specify your requirements. (Something Agile people know so little of these days it's unsurprising they should be banned from programming)"

Sorry, but this is nothing but complete denial of reality. Things change, especially in the technology world. I worked on a project for a client a few years back that would take a number of years to complete. At the outset, the goal was for the client facing portion of the application to be web based supporting IE6 and whatever the version of Firefox was at the time on desktops. Within 18 months Chrome came to matter, IE6 was finally being ditched left and right, the iPhone and iPad turned up, and mobile became a serious thing that mattered. Within the project's lifetime the whole way in which people used and viewed websites changed completely.

If you think everything can be foreseen at project conception, then you know literally zero about the realities of software development. You would literally need someone who can see the future on your team to be able to do what you're claiming successfully and consistently.

"Again, I guess you better let all gov agencies know that all their projects involving software prior to 2005 or so failed. Guess that moon landing really was on a stage somewhere."

You can't take the set of all projects and pretend they're all the same, it's a nonsense. For some projects waterfall works incredibly well, because we've done it a million times before. For software, it's simply not as clear cut. You're right, many government projects have been highly successful under waterfall, but look at a subset of that, what about government IT projects? Government IT projects are universally known to be a complete joke, precisely because the failure rate is astoundingly high. That is in large part down to a failure of choosing the correct methodology for the task in question.

"Having been exposed to a number of Agile projects that all ran over budget, schedule and/or failed, I can truthfully say Agile itself was the cause."

Oh not this old chestnut. This doesn't even make sense, the whole point in an agile project over waterfall is that it cannot run over budget or beyond schedule. The whole point is that you keep sprinting until you've spent as much as you want to spend for the deliverable provided at the end of each sprint. If what you mean is that you had a ballpark figure and schedule in mind before you started and you missed it, then this simply states that your estimate was incorrect and that you would've had to choose either way between spending more and getting the product you wanted, or staying on budget and getting a lesser product than you incorrectly estimated would be possible in the chosen time and cost bounds. It seems a little odd that you bitch about people saying you're doing it wrong, whilst also claiming that you're following the exact guidelines, only a sentence after you've demonstrated that you haven't even got the slightest clue about the fundamentals of agile in the first place. You clearly are doing it wrong, and are not following the guidelines, because the sentence quoted above alone shows that you do not even grasp the fundamental place of agile in achieving proper cost/time/quality balance.

I am not saying agile is a silver bullet, far from it, I firmly believe it's often used when it's a poor choice, and I firmly believe it requires fundamental changes to a business that most businesses do not need to make. I believe there are better options including using a hybrid approach to suit your businesses actual needs, rather than what some buzzword monkey is telling you are your needs. But some of what you say in your zeal to defend waterfall is just complete and utter nonsense because waterfall, like agile, is not a silver bullet either.

"In other words, you aren't describing waterfall in your comment. Yes, I'm invoking the "No True Scotsman" fallacy, since that is usually what is invoked when Agile is criticized."

No, he absolutely is describing waterfall, the problem is that most developers have gotten so used to waterfall being useless for a large number of development tasks that they've fudged it with semi-agile techniques naturally to get it to even work for them at all.

If you're going to criticise agile proper, rather than accept that as per your argument that what you're calling waterfall is necessarily waterfall with a sprinkling of agile, then you have to hold waterfall to the same standards and accept it as it was formally defined in the first place. You either take the formal definition of it and argue against that, or accept that many agile techniques are incredibly useful and pop up naturally when people fudge waterfall as their general development practice choosing not to apply either strictly.

Whether you've seen agile used successfully or not doesn't really matter, it's a mere anecdote. The fact is that there are thousands of companies out there, including some of the largest and most successful that do use it successfully to deliver software.

For what it's worth, my personal opinion is that agile, like any other tool in a developers box is something that should be used when it's the best tool for the job. I don't really see much benefit in developing complex back end architectures using agile, I find waterfall is typically actually a good fit here, because the whole point in such a backend is to get the architecture right from the start and have it flexible enough to support whatever it needs to support and such a backend will typically have years of life in it. In contrast, I believe agile is absolutely necessary for good UI design- the fact is you can't document a good UI from the outset under waterfall as good UIs have to be developed with a constant cycle of user feedback. It's a manual optimisation process that requires repeated analysis of analytics and user feedback to make changes that optimise the result, the whole feedback cycle of agile fits perfectly.

Agile can and does work, and it's not a failing concept at all - it's use is still growing, and it's still being used successfully. It is not however a silver bullet, and anyone who believed it is or was is probably worth ignoring completely.

Make no mistake, agile is not something you can just wedge in overnight, it requires big procedural, cultural changes, and even toolset changes. It's not merely a cliche to argue "you're not doing agile properly", it's a common fact that many houses jump on the buzzword and get it wrong because they do not recognise the scale of actual change that's required if they really do want to go wholly down the route of strictly applying some agile process (which they probably don't unless they're doing web and/or UI work). Similarly, it's also common that people do as you have done - fudge waterfall to have some aspects of agile to make it work. If you believe waterfall is as foolproof as you suggest, I implore you to go and read about waterfall strict, and apply it strictly, because what you're describing most definitely isn't it, in much the same way as describing throwing QA out the window most definitely isn't any strict agile methodology.

I personally have no qualms when designing, say, a client-server application, with having the server developed using waterfall, and the client developed using agile. don't know why people feel they have to be so tribal about waterfall vs. agile - it's not a fucking contest.

I know you think that by throwing insults at me you think you're upsetting me as some kind of consolation to yourself that you lost the argument, but the problem is kid, I was around when DIAF was created. To offend me, I'd have to actually take offence, and you're just not capable of throwing anything at me that could do that.

So here we are, with you throwing insults, thinking that's somehow making up for the fact you lost the argument. Yet all it's really doing is telling me how you're the type of guy who has insecurity issues, that is probably depressed, that needs to seek approval in online discussions, and that hits a low when they don't get it because they posted something that wasn't correct, with the net result being that they burst out in attack to try and deflect from their insecurity and failure to seek the approval they were after.

Give it up kid, learn to accept when you're wrong and gracefully do so. You'll feel a whole lot better for it. This? this just tells me I was right, that you can't take being wrong, this attempt at upsetting me simply fails, and just acts as confirmation that you know you're wrong, but are incapable of admitting it - your attack doesn't make it suck to be me, because it confirms I was right, it tells me that it sucks to be you.

To be fair, the European neonicotinoid ban is a bit half-arsed.

They banned things like Imidacloprid, yet Thiacloprid and Acetamiprid which are both also neonicotinoids have not been banned.

Conspiracy theorists in gardening communities (yes, they get everywhere) have this idea that the ban has nothing to do with the bees and has been carried out as a result of subversive lobbying by companies like Bayer whose patents on things like Imidacloprid are near their end can prevent generic brands entering the market and force everyone onto their still patented brands instead.

But I'm not one for conspiracy theories without any evidence to back them, mostly I'd rather just assume it's typical political incompetence to only do a half assed job of temporarily banning neonicotinoids to measure the impact rather than the result of a conspiracy theory, so take what you will from that.

I think it's unhelpful only doing a half assed job, because if things improve then companies like Bayer can say "Hey look, the bees are okay even though everyone is still using neonicotinoids like Thiacloprid!" and if there is no improvement, then they'll say "Oh, no change, so it wasn't the Imidacloprid so we can start selling it again" and environmentalists can say "Well, it's because other neonicotinoids are still in widespread use".

So don't expect our ban in Europe to settle anything. It's not comprehensive enough to offer any conclusive results one way or another. At best it may throw a bit more correlation into the mix, but we have a lot of correlation, and not enough causation already.

Any idea why they're delivered there at all? I was always under the impression California has a reasonable year round climate, so what's so difficult about them just keeping the bees there all year round?

It strikes me as far cheaper and easier to just maintain colonies locally, than dick around transporting them god knows how far.

Your argument doesn't really make sense, as the same arguments you've used against neonicotinoids applies to varoa mites.

You claim that neonicotinoids can't be to blame because there are no large scale bee deaths in places where neonicotinoids are used. Well guess what? there are places in developing countries where neonicotinoids aren't used for cost reasons, the varroa mite still exists, and that also don't have the problem.

Similarly, you claim that neonicotinoids can't be to blame because they were used for 15 years before CCD. Well guess what? The varroa mite has also been widespread in countries like the US for just as long.

You're applying double standards in your logic in an attempt to absolve neonicotinoids and blame the varroa mite. Your whole argument is built on arbitrary yet contradictory application of correlation as causation to suit your preconceived belief that neonicotinoids aren't to blame.

It's quite likely that a number of factors are to blame, and that neonicotinoids weaken bee colonies enough to ensure that varroa mite infestations lead to catastrophic collapse.

Well here in the UK, that's not how things would work and it's utterly stupid to have things working that way if they actually do.

Here you can be contractually obliged to turn over medical records if it's relevant to the job and the safety of others - i.e. if you're an airline pilot. As such, if you are in such a role then you have the freedom not to turn them over, but if you don't then that's treated the same as if you're not fit to fly effectively placing you on sick leave.

Normally though, companies have their own doctors on payroll, and you would go for an examination with them, and they simply check things that are relevant to the job (so if say, you had AIDS, then they wouldn't check for that or tell your employer if you're an airline pilot because it's irrelevant) and agree to have any findings handed over to your employer, again, you can turn it down, but that's treated the same as being sick without a doctor's note.

Optional checks are as useless as no checks in such a circumstance. If someone refuses to hand over such records, that's their right, but companies should er on the side of caution for safety critical jobs, not just say "Oh well, he hasn't handed it over let him fly anyway".

There still needn't be any prying into private life - only ensuring during work hours that he passes all the checks that are relevant to the job in much the same way that soldiers have to pass regular fitness tests.

Alright no need to cry, and get all upset, it's not my fault that you have no idea what you're talking about. That $1bn includes money to develop games outright, you know, key launch exclusives like Ryse that were also released on the PC.

Which, you know, is exactly what I said earlier. Quite how you think this translates to the idea that all developers are just as happy to spend as much to develop for the PCs as consoles I don't know. I guess you're just one of those retards who says things without understanding anything they're talking about, refuses to back down when faced with someone responding that does, and explodes in a flurry of tears and insults when it all gets too much for them.

You're bored of making stuff up and pretending you know what you're on about whilst simultaneously proving that you don't because you have too much arrogance to admit as much?

Okay then. Have it your way.

"There are certain off-work things that an employer should know about - witness the guy who intentionally flew the airliner into the mountain and killed all on board - when it can affect their on-the-clock performance."

Yeah but does solving that really require intrusion into his personal life? Isn't it something that could just as well be solved by making sure pilots have regular appointments during work time with mental health professionals to ensure they're of sound mind?

I don't see this as justification for prying into his personal life, only ensuring that people in charge of things like planes are regularly vetted to ensure they're safe to be in charge of planes. I think there's a distinct difference between mandating that your staff have their mental health checked on the clock - and if there's any doubt, suspended from the job - and prying into someone's personal life off the clock.

You can evaluate anything that might impact their time at work, when they're at work. If someone turns up drunk, you don't need the details of the night before, you just need to know that they've turned up drunk and aren't fit to work.