dreamfactory

The article seems quite confusing on a number of fronts.

Architects of buildings don't actually use waterfall for a start - they continually adapt and improvise (in response to things like variable materials supply, soil conditions, weather, unexpected archeological finds etc.)

The UCD practitioner as outlined here is a type of, or proxy for, a product manager, which would fit in very well with any agile process.

The insight about unionisation is interesting, but the fact that agile turns out to share some subset of traits with unions doesn't really say much about agile - as nobody designed agile as a form of unionisation by the backdoor. It could be entirely coincidental and irrelevant or it might reveal something about aspects of unions being an emergent property of labour. (We certainly see unions appear across many industries in most nations.)

The point about lean and agile seems misconceived to me. Agile is essentially about preserving your options for change by reducing batch sizes and thereby improving flow of business value delivered. Scrum is just one form of agile, which reduces the epic cycles of waterfall from 6+ months to 1-4 weeks. More lean-focussed approaches like Kanban just take that further to a granularity of individual features. In fact you will have much more measuring and chartism under Scrum. A major lean argument is that optimal program velocity is achieved by continuous flow, even where it means that some individual items move at a slower pace - much like traffic control. This is precisely not an inhumane 'whip the horses harder' PM approach. It is also easier to visualise without needing to constantly measure an refine - bottlenecks should be self-evident from a kanban board for example.

Design thinking isn't something I'd say was at odds with agile at all, but in my experience is considered part of the wider movement away from 'throw over the wall' approaches (along with devops and lean UX). It's fundamental to lean startup for example.

And Taylorism is misapplied by many people to software development. In one way you can comfortably separate conception from execution with software. You could call them design and production line. The commonly made mistake is to think of coding as a production line activity rather than one of design. In fact the process of software development is one of automation generally - just as a high level of standardisation allows you to have robots building cars, a high level of software design allows you to automate execution. Where you have shoddy design, you end up with an inefficient process with humans doing production line work - that's a failure of industrialisation and Taylorism, not an example of it. This is in fact why software projects that attempt to separate design from technical implementation always run into huge problems. The technical implementation isn't a separate thing but is the actual design (and UCD here is closer to discovering the goals than defining implementation).

The gas works well at preserving the coffee from oxidation. The bigger problem is with water temperature - espresso is incredibly sensitive and will become either sour or bitter if the temperature goes outside a very narrow band. This is what you are spending money on with expensive espresso machines - PID temperature controls and lots of heavy brass parts to maintain an even heat. Nespresso machines are pretty cheap and plastic and I believe they use specially made bland coffee blends to disguise this.

Frankly you are better off with French press or pourover at home.

The point I was trying to make is that you could hardly assemble worse 'data' if you tried. It's blatantly absurd from the coffee he used to test, and if you have ever had both Nespresso and decent coffee (e.g. just about any coffee shop in Portland) your tastebuds would need to be blind to consider Nespresso as on a par.

My own informal testing (which would seem to have at least equal scientific validity to the article) is based on friends and family A/B-ing my own decent home machine, some excellent local coffee shops, Starbucks, and a Nespresso machine I bought for a relative so that I could bear to drink their coffee when I visited.

Not trying to grandstand here but the article has misleading info (and may well be astroturf), that's all.

I don't mean after roast (whole beans should be good for a couple of weeks). The author had ground his beans 4 days previous to the test.

This is a bit ridiculous. Nespresso is best described as not bad and not good - it's drinkable in the same way as Starbucks. The technology is pretty rudimentary and the machines don't have sufficient boilers to get a consistent water temperature going through the coffee (tightly controlled water temperature and freshness of the coffee are the two main variables for flavour). The espresso they made in the test must have been pretty mediocre not to trounce Nespresso. (The author's coffee was never going to win any prizes - wrong beans, wrong grind, and 4 days old - a decent brew needs beans ground within minutes at worst).

How about you?

In light of http://www.washingtonpost.com/world/the_americas/report-snow... - I'd say it was pretty tough to make any credible case that NSA wasn't at the crux of the matter. Frankly to suggest otherwise just sounds like so much spin.

It's replacing a declarative syntax with a procedural one as far as I understand which is a huge (and unwelcome) shift.

I do love the idea of an API-centred Lego-ish software assembly approach, but imagining a future when my entire app solely consists of calls to API's (maybe 100's of them), I worry a bit about wait times due to serial blocking calls (and failover generally), and dependency management at a business level (how do I track when one of them goes out of business or is having some downtime). I guess there will have to be a big industry out of wrapping and managing lower level API's in higher level abstractions (just as we see infrastructure businesses built on Amazon).

since we all started walking around with internet-connected mobile devices with a ton of hardware sensors this got a lot trickier.

So you never heard of TIA and data mining?

So 'only following orders' is the defense here? And these orders (e.g. hacking Google's SSL endpoints, big data mining) originate from politicians? (And to call scrutiny 'tiresome' when the director baldly lies to congress frankly just compounds the general air of unchecked arrogance.)

You know Mussolini was a populist.

They are specifically not PoWs, that's the whole controversy.

You need to distinguish between democracy and populism. Democracy isn't simply majority rule but a voice for everybody.

It happens but you need to recognise the true cost. You always pay interest on the other side at some point. At the same time you weaken boundaries and introduce instability.

Bear in mind that LOC is an ongoing cost not an asset.

> what, precisely, would be the rating

Peer review aka open source.

I'd put forward the proposition that not only is there no need to measure productivity of developers, but that this is a counterproductive management approach.

1. You have hyperproductive developers (the famous 10x ones). Everybody knows who they are and you can hire or retain them if you provide the correct incentives.

2. Then you have the disaster zones - again they are easily recognisable.

3. With everybody else, _they are going to be as productive as they are going to be_. They will be trying their hardest as much as they can - if they didn't actually want to build software they would be in the disaster zone category. You can improve this via a process of facilitation using well-known approaches to improving the working environment (plenty of info in books like Peopleware for example). As a manager, your biggest problem is stopping them working too hard and burning out because your schedules will become increasingly erratic, and the effect of late hours is always a net loss over the longer term.

If your development team isn't effective, it's a management problem, not a developer one.

Seen how much people pay for enterprise levels in Omniture?

Indeed, the post is about crappy management and little else. This is the real story - we talk about scarcity of engineers but it's as nothing compared to the scarcity of effective technical management, which is an industry scandal IMO.

Agile PM would actually put process first and simply measure output because poor processes impact everything else and give you no chance of sustained success. You should be trying to optimise the conditions for optimal outcomes via facilitation. That's the reason you measure, to understand and improve your success as a facilitator for the whole team, not to track individual productivity. You shouldn't reward or penalise anybody on outcomes themselves but on ability and diligence (which should be blindingly obvious to a technical manager given any degree of engagement with the development process).

That's the Zen of good tech management!

Hardly, faster time to market is a value multiplier, not a loss.

Hats off re good promo and topicality - but I'd expect something a bit more broadly reflective and nuanced. Really don't think you've thought this one through. You seem to have taken a line for a walk and inadvertently reinvented the asinine 'nothing to hide' argument here. The whole thing about say, the Stasi, was that they were interested in all the everyday comings and goings, not the James Bond stuff. That's the depressingly mundane and terrifying reality of mass surveillance. That's why it was referred to as the 'boot in the face of humanity' by a smarter and better informed person than any of us.

> It could also mean reevaluating what you've made public, and deciding what should be secret.

aka chilling effect - surely you're not seriously advocating for it?

That's a variant on 'nothing to hide nothing to fear'. Plenty of average Joes in East Germany under the Stasi may disagree with that notion being even potentially benign in its outcome. I'd imagine you have doors and curtains/blinds in your house - most people do and it's not out of neurosis and paranoia.

It's considered acceptable if you are talking about her pre-transition life.

One way to keep on top of the KPIs

You are describing any terrorism here.

> This has happened time after time and shows no sign of stopping because of fundamental problems

Maybe in the US but it's not a fundamental of governments generally.