Sunday, March 22, 2015
Today, I was set to write about the FCC’s recent posting of its Net neutrality laws/guidelines/timid suggestions, but it occurred to me I'd have to download and read all 400 pages of the decision -- probably remember some of it too. That’s a lot to ask of me on a Monday. Besides, I won’t much care anyway until we see the tattered, smoking, blood-stained, bullet-riddled revision that limps out of the first few courtroom battles against Verizon’s radioactive, demon-studded legal team. Instead, I’ll write about how much I hate the Apple Watch because there’s surprisingly little on that -- I mean, surprisingly little.
That’s strange to me because the Apple Watch is quite obviously the tippy-top pinnacle of mind-control advertising straddling a gut-wrenching nadir of blind gadget trendiness. I hope I’m not coming across as too soft or wishy-washy. To be clear: I hate it. The only worse news would be if Apple infected every box with the zombie virus, though that would at least make it a smidge interesting.
Because I loosely qualify as a journalist, mostly due to booze intake, I was schooled to prep for the Grand Coming of the Apple Watch -- an event expected to have about the same impact on human history as the Magna Carta. To ready for its arrival, we in the Whiskey Estate were supposed to be familiar with its technology origins (obvious), its final design (mysterious), and its creator (mind-bogglingly rich and supernaturally talented in marketing).
But even during the carefully orchestrated “leaks” around its release, the Apple Watch seemed in no way new, yet its oomph only increased as the debut drew near, which had me thinking I was missing something important. I wasn’t -- chasing details on its creator, I was suckered into reading a 17,000-word bio on Apple design chief Jon Ive, a sudden powerhouse in Cupertino because he’s credited with inventing not only the iPad and the iPhone, but also a tasty 350-calorie chicken alfredo recipe.
Imagine 17,000 words on Ive’s hopes, his charming shyness, his chauffeured commutes, his pearls of corporate wizard-speak, and all the pomp and high arcana associated with allowing a reporter into the ultrasecret letdown that is the Apple design labs. That’s 17,000 words' worth of me rolling my eyes and whipping ice cubes at Maginot only to finally catch a glimpse of Ive’s mental masterpiece earlier this week wherein we find -- ta-da -- a Nano watch! Cue the polka music and party favors!
I had one of these things in 2009! Different watch faces? Had it with the Nano. Superficial health monitoring? Had it with the Nano. Photos, music, calendar? Had it with the Nano. Inflated price tag? Had it with the Nano -- though the A-Watch is in a league of its own here.
Perhaps in my codgerdom, I’m being too hard on the A-Watch. It is more than a Nano, which didn't have real connectivity or the horsepower to run iOS. Theoretically, this thing should be the sliced bread of bees’ knees, the secret sauce on the cat’s pajamas. The proof in the pudding would come from what you could do with the device -- besides swap back and forth between freshly downloaded Mickey Mouse and Goofy watch faces.
But judging by the apps showcased at the launch event, Apple pushed the “what will they do with it” question to the bottom of the design agenda, right after “blister-pack texture.” Taking a page out of the same book that killed Windows RT, Apple decided to let its ecosystem of third-party app makers come up with why we should buy the thing. Unfortunately, RT app makers and iOS app makers had pretty much the same idea: Take the apps they’re building for the parent device and shrink them down for a smaller screen, whether or not it's useful in any way (spoiler alert: generally not).
Of the 10 “early business” apps listed for the A-Watch, we have five SMS-style chat/notifiers, one task/reminder, two note-reading/taking, one email reading, and two time trackers. To recap: six apps that are both easier to use and more effective on your iPhone, one total fantasy (I will never read presentation notes off my watch), and two that offer me the ability to pay extra for apps that let me, er, tell time ... on a watch. If this thing takes off, my mom, Bill, Elon, and Steve will eventually be proven correct: Artificial intelligence will wipe us off the map, but only because gadgets like this will have devolved our brains into mushroom status and the AIs view it as mercy killing.
What’s really sad is many of us stopped wearing watches because smartphones took over the functionality. Yay, we had one fewer item to carry around or lose. But thanks to tech trendiness, a device we no longer need is coming back, and it's doubling down on the same functions as the device that replaced it -- but not all of them, not as well, and with an emphasis on squinting. And we have it all for the bargain price of $1,000 and our souls.
Insanity, consider yourself redefined.
at 9:10:00 PM
Can programmer productivity be effectively measured? Blogger Jim Bird joins the chorus claiming that it can't – at least not using traditional methods alone:
There is no clear cut way to measure which programmers are doing a better or faster job, or to compare productivity across teams. We “know” who the stars on a team are, who we can depend on to deliver, and who is struggling. And we know if a team is kicking ass – or dragging their asses. But how do we prove it? How can we quantify it?
Bird quickly debunks lines of code as a measure of productivity, noting that the best programmers take the time and forethought to do more with less code. Likewise, many executives would measure productivity by the value of the end product; does it make or save the company money? This measure doesn't account for the myriad business factors that can help determine whether a product or service succeeds, however, regardless of the quality of input from the development team.
So what other measures are there? Bird offers a handful, tweaking each one for a more precise result:
- Speed of development, or velocity: Velocity is intended to be used by a team to measure how much work they can take on, to calibrate their estimates and plan their work forward. It should not be used to compare productivity between teams, however, and it must account for changes in the team, as people join or leave.
- Cycle time – or 'just stay busy': Measuring time to product (the turnaround time or change lead time for new product development and release) gives an overview of the team's productivity. Better yet, look for and optimize out the bottlenecks and idle time that contribute to longer turnarounds. This measure encourages short-term thinking and cutting corners, however, because speed equals reward.
- Code quality: Fixing bugs later costs more than testing for them early and often in the development process, and there are many good ways to measure code quality. But does code quality directly correlate to developer productivity?
Read more on Jim Bird's Building Real Software blog, and get two more suggestions for measuring and improving developer productivity.
This story, "How to (and how not to) measure programmer productivity" was originally published by Java Everywhere.
Odersky also described the Dotc [pronounced "Dot C"] compiler platform, intended to help eliminate bugs and produce a better understanding of the technology. "We want to clean up some of the parts of Scala," he said. Overall, Scala proponents seek to make the platform more powerful and simpler, said Odersky, as Scala has too many types. Plans call for eliminating existential types.