WorkerBee

Banks - their back-end processing is often in Java.

Saying that UK public services are inefficient is one thing, probably true.

Saying that the layoffs can be confined to people who "aren't contributing anything productive" and be extension health, policing, education, research etc will not get worse at all is an entirely different thing, and I don't think it's true.

Experimentation and inventing your own wheel is good for learning. But most of the time those wheels shouldn't see a wider audience - unless they have something new to offer.

What specifically does this project bring that isn't present in ASP.NET MVC, OpenRasta, FubuMVC or MonoRail?

Or that couldn't have been achieved by porting one of those to Mono (if they aren't there already)?

Pretty much, yes. It made him seem like less of a monopolist.

Worked out to be a winning bet for Gates.

That's what happens when you bet on every horse in the race. It's something that Microsoft does a lot.

the interesting thing is that the agile movement started as exactly the reverse of what you said: as a grassroots movement among engineers that embraced flexibility, not a tool to pointy haired bosses to impose.

If your experience is the opposite, you've been had by someone, and you're blaming agile.

whenever unit tests or test driven development comes up the proponents act like anyone not doing things this way is incompetent. I think the reverse is true

The reverse would be "anyone doing unit tests in incompetent", which is not a defendable statement. What are you trying to say?

Yes it was.

http://en.wikipedia.org/wiki/Macintosh

"The first Macintosh was introduced on January 24, 1984; it was the first commercially successful personal computer to feature a mouse and a graphical user interface rather than a command-line interface. The company continued to have success through the second half of the 1980s, only to see it dissipate in the 1990s as the personal computer market shifted towards IBM PC compatible machines running MS-DOS and Microsoft Windows."

I believe that the best outcome for both of you would be 20% of time set aside for refactoring and increasing test coverage. Sure you'd want more but features have to roll out too. Management may not realise that refactoring that much is necessary.

You may have to pad out estimates of new work, and say things like "in order to do that we'd have to understand the guts of the foo subsystem, and make sure that we don't break it while we change it, so we'll have to put tests around it while we change the code" while mentally adding a week's time refactoring and adding unit test coverage to foo to your estimate. Grease the moving parts - things that change once tend to change again, and you'll be happier the second time around.

If you can't even do that, ask them what they mean by "take ownership". Maybe they just want you to the go-to-guy for that particular monster. Say what would do if you really owned it. If you are completely overruled, you may have to be blunt and point out that this is not ownership in any non-bullshit sense.

If that fails, as the wise man said: if you can't change your company, change your company.

I really can't say that Diaspora has been doing that better. Or at all.

Typical facebook users are not early adopters. None of these projects are even close to targeting typical facebook users yet.

"just the right amount of planning upfront" is exactly what Scrum should do. It's not full-circle at all, it's another approach to current good practices.

That statement misses the entire point of Scrum. What are those short iterations for, if not to get feedback from those using the software? Why replan at the end of every sprint, if not to know how user needs have changed and been informed by the current software?

How is the readme so different from the sprint's user stories? Working from the desired end docs looks like another version of the currently fashionable "pull" methods. Not a bad one for a particular kind of project though.

You don't get more energy out than you put in, but if your goal is to make helium, that's hardly the point - just about every other industrial process also consumes energy.

"All transactions are settled between the card and reader alone. Readers transmit the transactions to the back office in batches but there is no need for this to be done in real time." - http://en.wikipedia.org/wiki/Oyster_card

People here are saying "I think/guess/assume that oyster cards work like... ". Without even checking with Wikipedia. I'd like to hear about the Oyster card system's strengths and weaknesses from someone who really knows the system.

There have been visual app generators before, for other platforms. None of them took the world by storm, and mostly were very limited and/or actually quite hard to learn - different from regular programming languages, but still with a learning curve. The devil's in the details, and a good programming language "makes easy things easy and hard things possible". App generators often succeed very well at the "makes easy things easy" part but fail at the "make hard things possible" bit.

Are you referring to this? http://blogs.computerworld.com/london_stock_exchange_to_aban...

Despite the ignorant and inflammatory commentary that I linked to, I doubt that Accenture's failure to write a system in C# raised much of a wave inside Microsoft. Accenture could have made the same mistakes in Java or in any other language.