If your projects can't handle things like dependency lists, package managers, and actual planning, then of course it's going to fall apart like you describe.

I don't know about where you work, but where I work, people actually talk to each other and plan what versions and which frameworks we'll be using rather than just setting everyone off willy-nilly and pray that it all works before being pushed to production.

We have local workstations, dev servers, staging servers, and production.

Devs can do whatever they want on their local workstation. In any given week, I work on 2-3 different projects with radically different stacks. Central IT (which is technically outsourced to a stand-alone company that supports us and the other companies owned by our Fortune-500 overloard) has absolutely 0 knowledge of what we do and what we need to support our work.

Devs also usually have sudo access to the dev servers, but rarely install things there.

Devs never have admin access to staging, but they usually have the ability to do deploys from the build server.

Devs absolutely never have admin access to prod, and can't do deploys to prod either.

Dev team builds, tests and does whatever is needed on local and dev servers. They're responsible to make sure their stuff works and when ready for testing, trigger an automated deploy to stage. They don't have the ability to install any dependencies or configurations on stage, so if they run into problems, they need to negotiate with DevOps. QA validates on stage and has client do UAT on stage. If everything passes, DevOps manages the deploy to production.

That's a grand total of 3 "technical" people on the small project. Dev, QA, DevOps. Large projects will have multiple people in each role, but we still structure the same way.

No. Not if they are working on production code.

Why in the hell would anyone be working on production code on their local machine?

We're saying the same thing about Devs and Production environments. But somehow you've extrapolated that into Devs not having admin privileges on their local workstations which is absurd.

You completely misunderstood what I was saying.

Devs should have admin access *on their local machines* so they can evaluate libraries and platforms.

Devs and DevOps should coordinate and plan to decide which (if any) of those libraries should be included on the production environments.

DevOps should have nothing to do with workstation IT.

If you absolutely don't want to do any administration tasks, that's fine. But its a rare developer who doesn't throw a fit when management takes their admin/root privileges away on their own workstation.

It's legitimate for a developer to throw a fit. They should have admin access on their local box. There's an insane number of plugins, libraries, and frameworks they may need to install or test to determine if it's the right fit for their deliverable.

However, I fully expect DevOps to question every single add on and make the developer justify it before deploying to production. Just because I as a Dev want Ruby for compiling SCSS to CSS on my local machine to save me time, does not mean Ruby needs to be installed on the production environment. That's what build servers and deployment scripts are for.

SysOps on the other hand is far too prone to blanket say "No" or "We only approve this one obscure outdated fork of the package you want."

DevOps is the perfect position to reconcile developer wants with checks and balances against actual needs and responsible deployment.

Your value isn't in being the guru. Gurus get replaced because of the risk in only one person understanding how things work.

Your value is in being proficient enough that you can jump in and get up to speed in different roles, but have a general understanding that lets you step back and see the big picture.

Yes, getting your hands dirty is different pieces is key to this, but being the leading expert in each individual piece is the road to being pigeon-holed.

Amen amen!

We have dev ops, and I RESPECT the guys.

Why?

Because I'm busy solving the client's problems, and I have developers underneath me building databases, front end templates, integration platforms, CMS implementations and the works. I DON'T WANT them patching AWS cloud servers for Heartbleed because THEY SUCK AT IT. Likewise, I don't want an IT guy who just installs patches and walks away. My IT department acts like that, and because of them, I still don't have VMWare and test machines in the office even though they were approved 2-3 months ago.

I want people who can setup Git and Jenkins without handholding or wasting tons of time. I want people who can manage security and system updates. I want people who can figure out and get the right versions of Python, JVM, or NoSQL-DB-of-the-month installed without micromanaging. DevOps is an incredibly valuable role if you find the right people to do it.

Hint: If it requires interfacing with the client, it probably isn't a DevOps task.

We have that in the US as well. It's called witholding, and everyone not self-employed does it. If you don't there's penalties for underpaying come April 15.

The crazy part is that the US still requires everyone to self-report on this at the end of the year, even though they already collected the money. You're also expected to list all other forms of income, deductions, and credits and recalculate your tax burden yourself.

Annual tax review, reassessment, and filing should not be a multi-billion-dollar-a-year industry.

I had 2 options when provisioning UVerse.

Provision a multi-service line (and pay monthly for their modem/router) - or - Provision an Internet-only line and pay a one-time fee for their modem/router.

I did my research. The modems are different, and the line is provisioned differently. With the multi-service modem (even if I downgraded to internet only) I could setup passthrough and handle things with my own router. With the one-time-fee router, that functionality was blocked. Also, provisioning the line for multi-service and downgrading service to internet-only allowed for higher internet speeds than provisioning the line as internet-only.

So at least on UVerse, there was no option to not pay an equipment rental fee and get their maximum speed service.

We've spent 30 years training people that right-clicking is reserved for secondary extended behaviors, and left-click is for primary interaction.

And either way, I wasn't pointing to the fastest way to shutdown, I was pointing the defacto method of shutdown as encouraged by the interface that's explicitly designed to be intuitive for non-technical users.

Metro is a great concept, but fundamentally broken in its implementation as the vast majority of basic user tasks are overly complex, unintuitive, and don't even follow the standard UI practices introduced as part of Metro. Metro is literally inconsistent with itself.

Why is that popup menu I mentioned in the last step even there? I have yet to see that popup menu UI paradigm appear anywhere else in the Metro launcher UI. It's reminiscent of a secondary right-click menu on the desktop, but appears on primary behavior (tap, left click). Every other icon or menu I tap on takes me to a nested full-screen menu tree, tiles, or row of icons. Why does this one single menu get a floating menu relative to the button location instead?

I know I can rip this all out. I don't because this is a test VM for seeing what my average user sees.

If I perceive this as convoluted, confusing, and horrendously unintuitive, what does the basic non-technical user think? And they are supposedly the people this interface was built for.

Oh, I know. Windows+R, "cmd", enter. Type "shutdown /s"

I wasn't asking the quickest way to shutdown for a power user. I was pointing out the obtuseness of the basic, introductory way of performing a task. You know, the thing that should be the most intuitive, straightforward, process.

In what way is that remotely intuitive. Really? Ctl-RightMouse on brand logo?

Power-down is not an advanced user task.

And that logo doesn't even exist in Win8. It was reintroduced in 8.1

I just grabbed that as an example. Of course there are ways to work around the limitation, but the most basic elements of the UI have serious fundamental flaws. Some of these are easily correctable, but still haven't been 16 months and two major releases later.

Overall, I think the *idea* of Metro to be something interesting. A unified interface for both mobile and desktop devices is a cool challenge both from a tech and a design standpoint. It's also a bold direction for a company like Microsoft, especially Microsoft, to attempt.

However, the implementation completely fails. The graphics are great, the fonts, colors, etc, are fairly well thought out. The failure is in not thinking about the ramifications of forcing this interface onto the underlying OS layer that doesn't directly support it. Too many elements rely on older Windows interfaces (some going back as far as WinXP or Win2K). Too many basic user tasks (like shutdown) are hidden far deeper than they should because the interaction designers didn't consider them, and the downstream implementation teams just shoehorned them in wherever they would fit.

As someone who's done a lot of UI work, this is really challenging stuff to get right. What is intuitive is often counter to the aesthetic or the underlying technical behavior. It just amazes me how Microsoft let such a flawed experience ship. Why did they bet so heavily, but not put the resources in place to ensure success? Metro could have been a lifesaver for Microsoft if they had actually executed on it thoroughly instead of the usual approach of slap another UI layer on top of the most commonly used elements but leave everything underneath identical to previous versions.

Yeah, vector photographs, those work great!