sfamiliar
Joined 18 years ago
Joined 18 years ago
comparing two programmers is possible. comparing a single programmer against a theoretical ideal is improbable. finding a remotely accurate formula for measuring developer productivity and yielding data that's actionable in the business space is really, really unlikely.
1) how much does joe's paintjob increase the value of the home for the HGTV-obsessed house-flipper?
2) how much will the value of jim's watercolor appreciate after he kills himself following a week-long binge of heroin?
put another way: how efficiently is value being created? the important answers lie more often in the decision process, and less often in the implementation schedule.
for example, a web developer working on a brochureware site: the right question may be along the lines of 'how will the work you're doing affect the conversion rate?'. in reality, those decisions aren't up to him -- the might lie in the internet strategy department or some such. they push the order, the developer implements. a real measure of results is closer to 'did the designer make the right decisions to yield results?' rather than 'did the developer get the code done more or less quickly than last time?' in my experience, when someone who is a non-developer is trying to quantify developer 'productivity', what they're really doing is dodging the question of whether or not their decision-making was good or bad, usually when they know it's bad and are looking for something to roll downhill.
more interesting to me, as a developer and sometimes manager, is whether or not a developer can deliver when they say they can? if clay says it'll be done in a week, and then it is, he's been sufficiently productive. 'sufficiently productive' is maybe the best thing we can do. the race analogy is an apt one -- if developer 1 can produce a set of functionality with the same defect level faster than developer 2, we can say that d1 is 'more productive', but it's a difficult thing to quantify absolutely. take the number of hours a developer spends working on a given project point, multiply it by their hourly rate, and you get a development cost for that project point. then consider the value that project will add to the product, over time. if you have 30,000 customers who haven't bought the product yet because it doesn't have Feature X, and adding feature X costs dollars Y, then your value-add is something line Z= customers * product price. your efficiency is something like Z/Y.
clearly you want to minimize cost, and therefore keep your efficiency as high as possible, but the ways to manipulate that, and a lot of points to consider:
a simple example -- if you can hire a developer that will take twice as long, but work at 1/3 of the rate, would the revenue lost during the extended development period negatively affect the profit efficiency?
the important questions are somewhat higher up.
for a less-than-complete guide to ruby 1.9 features, consider reading eigenclass's summary from way back: http://eigenclass.org/hiki.rb?Changes+in+Ruby+1.9
consider instead gold, silver, platinum, and jewelry. since we're talking about an 'escape scenario', they might be your best option. mr. wemmick in 'great expectations' had a not-terrible plan in terms of an unstable economy: he had gems and jewelry pinned under his lapel, and frequently touted the value of 'portable property'. this might be a better route to take than currency since it doesn't fix a destination, it's easily liquifiable, and very portable.
if you want processing power for web servers and databases, get a slice somewhere -- they're pretty affordable. don't buy an entirely new machine when you can get everything you asked for in the first paragraph for the macbook (and the sync hassles that come with two machines). you'd have to buy that stuff anyhow if you got a desktop, why not get it without the desktop?
my setup: three slices, a macbook, 25" 16:9 flatscreen LG in portrait mode. i use the mac keyboard, but have a really comfy chair. there's a file server in the kitchen, but it's left over from an old desktop and is not a speed demon -- it doesn't have any inputs or outputs connected save for ethernet.
that said:
if you're a resident in a company with a separate marketing team, it's key to speak their language -- after all, the people you're going to be marketing -to- is the marketing team. it's their job to get the message out, it's your job to be sure they know what the message is, and what it isn't. make sure you don't oversell, and let them know what would be overselling, and promote key features internally; they'll get external through the firm's marketing wing.
if you're a startup, marketing is doubly important. if you can't sell a friend on the idea of a product, you won't be able to sell the public. if your startup idea is complex, you're going to have to find a way to make it intelligible in ten seconds by picking the key features you want understood. and everyone in a startup is on the marketing team, whether they like it or not.
it's really worth it to read a book or two on marketing, if for no other reason than to get the lingo down. i've found my suggestions much better received when i could speak market-speak to the marketing team and sales team, and promote effectively to civilians. i recommend 'the culting of brands' by doug atkin as a good start.
we use slicehost and really dig it. will this adversely affect our service and pricing? time will tell.