I like the article, and would love to apply, as "management" in my own company, effective measures to cure the pain instead of treat it. In fact, I generally try to do just that.
But what this is basically suggesting is "locking out" your employer. While I agree that is absolutely what should happen, doing this without the leadership AND the developer in agreement about why sounds like disaster.
I know it's likely impossible to capture all the work and discussion it takes to reshape a company's process in a blog post, but I feel like if I had a dependence on OT in my company (as the "patient"), and a lockout went into effect, I would be focusing on the lockout, not every other problem in the company that caused it (which as management, it's my job to figure those problems out). What is being suggested is basically arm twisting to get what you want :/
That never works when you cause more pain to the company than it's able to alleviate over time. They'll eventually get tired of the pain and move on to another drug unless you succeed in getting them to understand.
I feel like better advice is to tell developers that they need to discuss this with their direct reports, boss, whomever, and talk about the problem and WHY you'll actually make the company better gains at sustainable pace. And by all means, point out and suggest ways for your boss to improve things.
If after educating your "patient" the issue still persists, of course, twist away. But not everyone in this world needs these sorts of tactics to improve their workplace, and even in those workplaces, there are likely more successful ways to cure the pain, not just treat it.
The suggestion isn't to introduce the lockout after the fact. In fact, what you're describing would be the exact thing that would happen in the metaphor -- acute withdrawal symptoms. The suggestion is to institute the lockout before dependency has a chance to develop.
Ah, well, I completely agree there :) Forgive me, but I didn't really catch the preventative portion of the essay. Looking back over it, I can certainly see your point above and we're more than likely "violently agreeing", heh.
Seems like we're both saying "an ounce of prevention..." here
A preventive measure by the C-level management will yield results: a person working overtime, must take a documented approval from the PM. The incentive bonus for the PM must be negatively linked to the number of overtime hours spent by the team members.
We absolutely are missing parts of the story. Negotiations and contracts at that scale are going to be massively complex, I can only imagine. Even my small shop's contracts with other businesses are multi-tiered and fairly dense.
Surely there is far more to this than simply "throwing weight" around by Apple, unfortunately. As well, it hasn't been that long since the carriers ruled everything about our experience with our phone. I'm sure there's plenty of old bureaucracy left for getting them to say "yes" to what all of us would want.
Perhaps, even, the things that frustrate you were some of the things Apple had to give up to give us the other awesomeness :P
Your reaction was my initial reaction as well, and definitely one I sympathize with (which made me actually comment). But, after thinking about my own basic experiences with contracts (and if you've ever signed a mortgage, for instance; a daunting amount of contractual repercussions, heh), I can only imagine the war room that negotiations must be with those carriers.
But all that, of course, is conjecture... Apple could just be assholes :P
Maybe I'm displaying some extreme naivete here, but I thought Apple did a spectacular job during the original iPhone launch proving to the carriers (and to the world) that they really didn't need them in order to move phones. Despite the fact that the original iPhone didn't even have any subsidy and yet STILL required you to sign a 2-year contract with AT&T (what!), Apple moved units like CRAZY via their own direct sales channels (Apple retail stores and store.apple.com).
It seems to me that given this fact, there really is no reason why Apple has to continue to kowtow to the carriers. Apple should stop sucking up to them and push direct sales of unlocked phones harder than ever. People will still buy them. They should then show a complete and fearless disregard for carriers by discarding the concessions they have made to them in the hardware and software design. Just throw stuff like carrier profile restriction features completely out. Sell iPhones to and for your end-users again.
If Apple decided to actually do this, what could any of the carriers really do about it? Nothing, that's what. Ban the iPhone from their networks? They wouldn't dare. (Or at least the GSM ones wouldn't...IS-95/CDMA2K is a slightly stickier subject, I'll admit.) There always seems to be a lot of talk (especially State-side) about carriers being open-access and what that means (remember the rider on the 700MHz auctions that Google convinced the FCC to sneak in which Verizon is now bound to as the winner of that spectrum block?), but GSM carriers have always mostly been "open" with respect to devices. Part of the promise of the SIM "personality module" is that it brings to the wireless industry what modular plugs in the home brought to the wireline industry following events such as the FCC's Carterphone ruling: a decoupling of the carrier and the end-user's device. I want to see the wireless industry move in that exact same direction. Sure, AT&T could decide to block iPhones from their network, but then they'd be turning down revenue from potential customers solely out of spite, and they aren't going to do that.
So far, the only company to have the balls to pursue a strategy like this, surprisingly, is Google. For some time now, you've been able to buy an unlocked Galaxy Nexus phone from them at a very reasonable price, and the Nexus 4 continues that tradition and even goes a step further: the ONLY sales channel (at least at this time) for the Nexus 4 is direct from Google. There are no subsidized or carrier-locked versions of this phone sold through carriers. There's a single SKU (well two, really, if you count the two fixed storage capacity options) for an unlocked GSM/UMTS phone. Google may have consulted with AT&T and T-Mobile here in the States out of courtesy before releasing the phone; I don't know. But I don't think that there's anything that says they had to get their approval to make and sell the phone, and there's nothing that says a user can't buy one without consulting their carrier first and put their own SIM card in it once it arrives.
Some may point out that Google isn't moving very many phones by themselves at the moment with this sales system, so doesn't that prove that this is not a viable business plan? I would counter that Google doesn't have quite the cachet that Apple does in this market at this time for reasons completely unrelated to how phones are sold, and that Apple, unlike Google, is in a position right now where it hold all of the cards. And for the sake of the consumer, Apple should take advantage of that position. That they don't appear to be ready and willing to do this (and in fact seem to be trending in the opposite direction) worries me.
I definitely salute Google for their move, and wish other phone manufacturers would follow in their footsteps. C'mon guys: take your destiny into your own hands rather than leave it in the trust of the carriers. Seriously.
Shreveport, Louisiana - Full Time - Rails/iOS Agency
Twin Engine Labs - workwithus@twinenginelabs.com
We're an award winning, cutting edge design and engineering shop. We bootstrapped our company from two people (designer and engineer) to 11, and along the way learned a lot of lessons. A few of them are:
1. Building tools that make our jobs easier in the future is smart and gives our agency an edge. You will be expected to constantly try to improve our process, and your voice will be heard.
2. Following that point, if you think something should change? Do it. Let me know about it (CEO), get buy in from the other engineers, and don't wreck our timelines. But stop talking and start doing!
3. Salespeople will never estimate your project officially. Ultimately, I will bring in a project, lay it in front of you, and ask the team to do a planning poker session. Your velocity is set at a scant 10 points, and the timeline is bid against that initial velocity. Under promise, over deliver.
4. If you estimate poorly, you are expected to fix it. If the project just went off the rails due to things out of your control, then your feet won't be held to the fire, but if it's genuinely your fault, fix it. It's completely in your control.
5. Try the impossible. We built The Fantastic Flying Books of Mr. Morris Lessmore, an impossible feat for it's day. We've built complex interfaces for Cisco, Symantec, and now are working with O'Reilly. Don't be afraid to use 2D Game frameworks if you have to. People don't contract Twin Engine Labs to do the status quo.
6. Be a full stack engineer. Know iOS but not Rails? Talk to us. Know Rails but not iOS? Talk to us. You will be placed in projects of your capacity, but very quickly ramped up to both platforms. We expect you to know everything from server deployments to iOS deployments, to Postgres optimization to Core Data optimization, from caching in Restful APIs to caching NSURL connections. Being a full stack engineer allows you to move faster than every other shop out there.
7. Finally, work directly with the customer. You, as the engineer, will always be expected to speak with the customer faster than I can. I will always give you air cover when you need it (and I typically can see that coming from a mile away). As well, you'll hear their requirements from their mouths (no games of telephone here), and get to ask them questions, with the safety net that I always stand behind our employees.
Perks? Multiple projects in a year, constantly learning the cutting edge techniques, and some seriously huge names under your belt.
Our environment is flat. No Pointy Haired Bosses allowed or bean counters here. Paint yourself purple, turn yourself upside down, and spin around three times while you code. As long as you deliver, I don't care how you do it.
Employees come into work at what is a reasonable hour to them. Our employees set their own start times, with flexible work at home situations when required. Most of them come into work because... well... we like each other :)
Intrigued? Talk to us. We've helped multiple entrepreneurs sink funding, watched multiple apps receive awards, and are known in our region and nationally.
I'd be interested in knowing what programs you've had trouble with? In Awesome, you can switch your layout to a floating-based one (oddly default without some rc tweaking) and get around most issues these programs face. Or just switch it to a full screen-based layout :)
Anywho, figured some examples might give others' a heads up before devoting hours and mind share to trying it out.
Java (at least swing) apps behave oddly, by which I mean they show up as grey boxes. According to the xmonad faq, the problem is that Java uses a hardcoded list of wm's (rather than properly responding to wm events) which does not contain xmonad.
I've been using AwesomeWM in Ubuntu 10.04 since pretty much the day Ubuntu 10.04 came out. My hesitancy with Ubuntu always lay in a good browser (I'm a web developer), but with Chrome/Firefox as good as they are, I didn't really have an excuse anymore.
I used to be a Mac/TextMate zealot (Rubyist, go figure), and have wholly switched over to AwesomeWM, Vim, and a host of other open source tools and will never look back. I just feel like an incapable two year old with a messy desk trying to work in a floating WM like OS X/Windows now.
If you want to try AwesomeWM, but don't want to risk going crazy from setting up xinit scripts or scrapping all that vanilla Gnome install gives you, follow this wiki article and it'll side side-by-side in Gnome: http://awesome.naquadah.org/wiki/Quickly_Setting_up_Awesome_...
I get NetworkManager support, audio support, bluetooth, and battery life all out of the box. As long as you're not a purist about what's running in your WM and what's not, this setup works great with little risk/time investment.
It's not a tiling WM, but augments the standard OS X window management keyboard shortcuts with grid stuff, and doesn't have any odd side effects with GUI apps.
Personally I think OS X and its app population comfortably swing the overall usability balance vs desktop Linux so I won't follow your footsteps :-)
I've seen and tried sizeup before I made the switch, and though I feel that it's a great application and a great step towards a middle ground for tiling, it is most definitely not the same thing.
Being able to have windows automatically be positioned is key to the tiling wm, I feel. It allows you to have a layout work as you'd expect without fumbling or thinking about it.
I do agree about the inaccessibility of desktop Linux (though it seems to be getting so much better these days!). A previous co-worker of mine uses AwesomeWM every day inside of a VMWare instance with Mac hotkeys disabled and loves doing that. Might want to give that a shot if you like what SizeUp gives you.
But what this is basically suggesting is "locking out" your employer. While I agree that is absolutely what should happen, doing this without the leadership AND the developer in agreement about why sounds like disaster.
I know it's likely impossible to capture all the work and discussion it takes to reshape a company's process in a blog post, but I feel like if I had a dependence on OT in my company (as the "patient"), and a lockout went into effect, I would be focusing on the lockout, not every other problem in the company that caused it (which as management, it's my job to figure those problems out). What is being suggested is basically arm twisting to get what you want :/
That never works when you cause more pain to the company than it's able to alleviate over time. They'll eventually get tired of the pain and move on to another drug unless you succeed in getting them to understand.
I feel like better advice is to tell developers that they need to discuss this with their direct reports, boss, whomever, and talk about the problem and WHY you'll actually make the company better gains at sustainable pace. And by all means, point out and suggest ways for your boss to improve things.
If after educating your "patient" the issue still persists, of course, twist away. But not everyone in this world needs these sorts of tactics to improve their workplace, and even in those workplaces, there are likely more successful ways to cure the pain, not just treat it.