Just started playing around with zooomr. There are some things that I like about it and the way it handles geotagging, but I haven't quite groked the interface yet. It's definately different than Flickr, and that may or may not be a good thing. It relies more on AJAX, that's for sure.
More comments as I play around with it...
When I posted a couple of links the other day relating to software/management consultants, little did I know that today I would be living in an Office Space moment.
Long story short, my boss's boss needs to show that he is doing something about some of the issues we've been having (most relating to 3rd party tools, but I digress) so he brought in a consultant to find the silver bullet.
What's the first thing this consultant asks for? SLOC.
The next thing he asked for, however, really and truely boggles my mind. He wants to know the number of columns in our database schema. Not tables, but columns. This seems even more assanine then knowing SLOC.
Apparently he has some sort of tool that will tell him how many man hours it took to build, etc. Not sure how that factors in, but I'm sure it doubles the estimates or something. There's some geeking out after the jump, but I leave you with this fun little motivational poster.
Let's take a further look at why SLOC is bad. I present the following two pieces of code as an example (sorry for those that can't read C, that was easiest for me). They both print "Hello World!" however the second one introduces some error, and some potential for error (if you're a geek, you should be able to spot it immediately).
#include <stdio.h>
int main(int argc, char **argv) { printf("Hello World!\n"); return(0); }
And the output from the SLOC tool:
Total Physical Source Lines of Code (SLOC) = 6
Development Effort Estimate, Person-Years (Person-Months) = 0.00 (0.01)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 0.04 (0.45)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 0.02
Total Estimated Cost to Develop = $ 126
(average salary = $56,286/year, overhead = 2.40).
#include <stdio.h>
int main(int argc, char **argv) { char *p, *out_str;
if ((out_str = (char *) malloc(11 * sizeof(char))) == NULL) { fprintf(stderr, "Unable to allocate memory\n"); return(-1); }
p = out_str; *p++ = 'H'; *p++ = 'e'; *p++ = 'l'; *p++ = 'l'; *p++ = 'o'; *p++ = ' '; *p++ = 'W'; *p++ = 'o'; *p++ = 'r'; *p++ = 'l'; *p++ = 'd'; *p++ = '!';
printf("%s\n", out_str); return(0); }
And the output from a SLOC tool:
Total Physical Source Lines of Code (SLOC) = 25
Development Effort Estimate, Person-Years (Person-Months) = 0.00 (0.05)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 0.07 (0.80)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 0.06
Total Estimated Cost to Develop = $ 562
(average salary = $56,286/year, overhead = 2.40).
I could have made the second one even more complex, but I decided not to. According to SLOC tools and consultants, the second option is worth more even though it is more prone to errors (buffer overruns), and is slower (dynamic memory allocation). Apparently the first example took a little under 2 hrs to write, and the second took just over 8 hrs--or one working day--of effort. Egads.
For comparison, here are the stats from the current project I am working on:
Total Physical Source Lines of Code (SLOC) = 459,796
Development Effort Estimate, Person-Years (Person-Months) = 124.95 (1,499.36)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 3.35 (40.25)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 37.25
Total Estimated Cost to Develop = $ 16,878,548
(average salary = $56,286/year, overhead = 2.40).
Although I live in a country that requires the ability to vote electronically, I am happy to state that in Cook County, IL, I still get a choice. I was pleased that when I went to vote this morning I was presented with the option to vote paper. It's not as easy as punching a punch card anymore--it's done with a huge scantron sheet--but at least there is a verifiable paper trail.
I think what made me happier was the number of people, when presented with the option, either firmly chose paper, or asked "is there some sort of paper verification of my vote with the touchscreen?" Now, that being said, there were a lot of lines to draw on the paper scantron sheet. At one point my laziness kicked in and I was wishing for the touchscreen, but I feel more strongly about the need for a paper trail.
Apparently 90 other people in my precinct before me did, too, as the ballot verification machine had a counter on it.