This pre-history is fairly entertaining in that it exposes the low-effort groupthink of these tech bloggers/pundits/opinionators. The limited imagination is evident by most just putting together the iPod and the iPhone in the most obvious of ways: click wheel iPod with phone dialing functionality. Oh wait, how do you dial? Let's propose a slideout keyboard, yeah, that's it! And half those interface mockups look like a PocketPC screenshot with an Aqua theme.

Imagine if Apple did actually put out such an iPod + clickwheel + keypad combo, behaving like an iPod + dialing features or behaving like a PocketPC/Windows Mobile phone of the era. It would be a flop in comparison to how well the iPhone actually sold.

The moral of the story is that it takes critical thinking to truly innovate (that, and a massive design effort that's focused on user experience and not a feature list).

I ask you that you go into it with an open mind. Agile stuff has been treated as an overhyped bogeyman (look at all the posts here) and understandably many of us geeks are very cautious to approach it. However, if you pull the layers of hype and bullshit away, you recognize that it's just a different mindset that guides the work. This mindset happens to work a lot better with people and software (I am now convinced of this).

I'm hoping that you have a good instructor for training. But also, I am hoping that you have access to that instructor for questions afterwards, because that's really the most useful part. Every kind of training I've seen presents idealized examples to some degree, but a smart instructor will be able to tell you how you can work your situation.

For example, for varied skill sets, once you make up your team, try to take on a mix of stories (simplified use cases) that *approximately* reflects the skills breakdown. For example, if you have only two people that can touch your matrix code, take only on one or two matrix-work-intensive stories per sprint. After all, you have to be realistic.

(However, maybe a third person on your team would like to learn this matrix code. By sitting that person down with the matrix code expert and going through several dev tasks together, that person may learn something and may pick up these skills. Sure, it will feel slower at first, but now you have greater versatility in your team.)

If you are primarily doing fixes, then just reflect that in your wording of the stories. For example, we had to do some work to improve the startup performance of our product. We came up with stories that said, "As an administrator, I want my server to restart in less than X seconds." When we did some loose estimates, we realized that this was too much work to fit into a one-week sprint. So we split it into "As an administrator, I want my server to restart in less than X seconds, on Windows" and "... on Linux." This is because after doing some investigation, we realized that there was a lot of different work to be done for Windows vs Linux. This is not a perfect split of user stories (you want to keep such platform details out as much as possible), but that's OK. Do what works for you.

I have resolved to myself that, if I can help it, I am never again going to work at a place that does old-school waterfall. My team right now is in the middle of a transition to a Scrum-esque approach. We are running into plenty of problems, our team members have varied skills and some are much more versatile than others (Etc etc). However, it's already a better situation than what we had before.

So far, I am enjoying working off a prioritized product backlog, concentrating on getting smaller features DONE DONE, working in short iterations (2 weeks), and having the team who is fairly open to "let's change it if it doesn't work".

For one, many times before, spend months nailing down a long list of requirements, estimating the whole freaking thing, arguing between product management and engineering, cutting things to try to fit a set of features into some deadline (based on start-of-project estimates). Our product management would fight to keep certain things in that were important but not that important (because they did not want them to get dropped until the next release, that was many many months away). The developers (including me) would sit there, pulling estimates out of our collective ass for a ton of features, with barely any information for some of them.

Then we'd write extensive software requirement specifications (SRS) based on what was agreed to be implemented. The QA would go off to write test cases based on those SRSs. Of course, the use cases in these requirements were too detailed in some respects and not detailed enough in others, and completely missing the boat in yet other aspects. But, since they were signed off as "complete", we spent the rest of the project following what was agreed upon in the beginning instead of adjusting to the new process.

NOW, with the new process, we only estimate maybe 2-3 months of work, and even those we do loosely, using relative sizing (this thing is way harder than this other thing, this other thing is much easier, etc), without doing detailed task breakdowns. We only do detailed task breakdowns for stories (think of them as simplified use cases) for the next two weeks. Those task breakdowns are pretty detailed (we try to split tasks until they can be done in a day or less), but, again, we only do it for 2 weeks worth (every 2 weeks). This spreads out the pain.

So the benefit is that we only take on the most important work first. We can only do so much stuff in the next 2 weeks or two months. So all this detailed planning happens only for the most important things that the product management cares about. Every 2 weeks, the product management can reshuffle priorities and that's ok! No problem, we'll take on whatever is required next.

Developers are liking this because they don't spend weeks and months estimating everything under the sun. Product management is liking this because they can shuffle things around as market conditions change or other information comes to light.

ALSO, focusing on done done done. We used to have this "code complete" date. So some features took way longer to get done (often due to unexpected technical problems... sounds familiar?) and some were quicker than expected. Since one or two people would be working on each feature over the period of 6 weeks or longer, and even then, they only had to report some progress over those weeks. The "code complete" (or "feature complete") date was the date by which all features needed to be finished. Then we'd test and fix any bugs.

So, of course, what happens is that if the feature had technical issues, some coders would rush to check in code without writing enough tests or really even just testing it enough. Often, they would compromise design just to get it in by the date. So often, we'd have poor, half-baked code checked in by this "code complete" date. Now, testing afterwards starts revealing issues. Sometimes, the issues require a design adjustment, but now it's too late to make that design adjustment because we are in this "endgame."

Of course, you can make an argument that a better developer would not call a feature complete without sufficient testing. This better developer should've gone to the manager and said "this can't be done by the deadline" and let the management deal with that. The reality is that in a typical larger corporation, we have a lot of not-so-better developers, who are content on just cranking out something that qualifies as "coded" by this "code complete" date.

SO, by focusing the team on having smaller features be really "done" AND demonstrable by the end of the iterations really forces any issues to the surface. The feature has to be fully tested and work or it's not done. Oh shit, we have technical issues that add work and means we can't finish functional tests for this sprint? Well, no functional tests, then it's not done. OK, so that comes up right away (or at the latest by the end of the sprint) and we can then deal with it by readjusting stories, tasks, etc (and everyone realizes that this is OK).

By talking about the process and how everything went every 2 weeks, we have a chance for people to complain. Because all agile processes encourage adjustment and feedback, you can try things one way for a sprint or another way.

Of course, all of this requires management and coworkers open to change. You will find that most are open to it.

The problem is that now you're at the mercy of the cop. Not sure how they are where you live, but between me and my friends here in good old Massachusetts, we have been illegally searched by a pissed off statie, many times pulled over for bullshit reasons (were not the ones speeding, were not the ones peeling out in a nearby parking lot).

Do you ever play a little much with the radio in your car, looking too long trying to dial in a specific radio frequency? OK, so that's an instance of distracted driving that's as bad as typing a text message for the same 10 seconds, for the same basic reason that you are not paying attention to the road. Have you been involved in a really intense conversation (fighting with your girlfriend, e.g.) while driving and were deep in that instead of thinking about what's around you?

Have you ever spent too long starting at the windshield-mounted GPS screen trying to figure out just where the hell it's telling you to go? Distracted driving. Have you spent too long fishing around in your car for that gadget or sandwich or whatever else you were trying to get?

Anyways, distracted driving is a driver's mindset. You are either aware of the fact that you are not looking at the road when you do certain things and then you do your best to NOT do those things. Or you are not aware and you do other dumb things, in addition to texting.

So what now? I am sitting at a red stoplight, which I know takes at least a minute to switch. I can't take 10 seconds to text someone that I'll be late? It's perfectly safe and the worst thing is that I'll get honked at if the light turns green before I pay attention. I have made a thoughtful, careful choice. Yet according to the law, I am as bad as a drunk driver. Fuck yeah America!

  In my opinion, it would've been more effective to start education campaigns and enforcing extensively a simple moving violation ticket. Nobody wants to get a moving violation because your insurance rates start going up (no matter whether you were ticketed for a 5mph over or running a red light). With enforcement and public education, you would've had much higher impact than by declaring that you can face a 15 year jail sentence.

The only people who are truly happy about this are the lawyers who are about to get a lot more business than DUI defense.

Traffic fatalities rates have actually been steadily going down in the recent years and are lowest they ever were. I think this is mostly due to better cars (for example, stability control reduces accidents by about 30%, we have better tires, fewer old cars on the road that can't make a good evasive maneuver).

Cloud computing must work terribly, which explains why services like Amazon EC2 are totally going out of business, making no money and have no customers.

You use the search engine to search for stuff you want to find.

Then you measure accuracy by looking at your face:

1) smiling face
2) frowny face
3) monitor been punched because you're on the 10th page and there is still nothing relevant

It's next to impossible to change the speed limits, which are set unrealistically low. We have highways (Masspike here in the US) that were built for a safe 80mph using car technology from the 60's and the 70's--yet, we will never see this speed here, because soccer moms are going to cry murder and "think of the children."

The fact is that the police enforces 80mph on the Masspike as the de facto speed limit. If you are doing over 80mph, you are getting pulled over guaranteed, but 75mph and nobody will touch you (unless the officer is having a bad day, or, these days, a budget crisis). The police knows that these speeds are safe and even the state police chief acknowledged that people speeding moderately do not present a problem.

The other fact is that we will never get the speed limit changed to 80mph to acknowledge what's going on now.

So yeah, how can I change the law?

Lack of attention, people not looking where they are going, not checking their mirrors --- these are the factors that cause accidents and kill.

But, of course, getting people to actually pay attention while driving is a much more difficult task than jumping on a horse of "speed kills" and spending taxpayer dollars on bullshit measures like these.

I think that cases where .22s are blown are not going to be thrown out just on a faulty breathalyzer argument. Those people are usually detained and then have their blood tested at the police station. Anyone who is that drunk (and is clearly very dangerous) is going to have a way high reading even two hours later. So, in those cases, there should be a mountain of evidence.

Breathalyzers reasonably have a 30% margin of error, sometimes even more, depending on physiological differences between people. People get DUI tickets at a sobriety checkpoint for drinking two glasses of wine with dinner and registering enough to be over a 0.08, or worse in some states, a 0.06 BAC limit. That's ridiculous.

Try a different pair of shoes. Go to a running store and tell them you get shin splints... I've known several people who have switched to different kinds of running shoes and shin splints went away.

I agree... marathons seem ridiculous to me. 26 miles, hours and hours of beating yourself up? People throw up during and after marathons because their body is so stressed. That's not right! That's dumb!

Many people running marathons are misguided. They run a marathon for the sake of pushing themselves past the limit. Most of us geeks know that there's a limit to how much you can push things and there's no point in going beyond it. You can make an overclocking analogy here...

It's a hobby that some take up because it has societal respect/recognition (who's going to make fun of you for running 20 miles in one day?), and they quickly disregard things like, you know, safety, progressing at a safe pace, etc. Instead, they think "my body hurts but I just gotta keep going!" And then fail.

I do think that running is good though. I just began running at the age of 26, after not ever having done that, and I enjoy runs of moderate distances, along somewhere nice and scenic. 3 miles is perfect. 5 miles is probably as long as I'd really want to continuously run. I've done 7 miles in a day, but that was a 3 mile run and then two 1.5 miles after a long break (and I still had energy and motivation).

I find running enjoyable, surprisingly so... I stream some live Internet radio over 3G on my phone, which helps keep my interest up, and then I just run and enjoy the fact that I'm getting a good amount of exercise. Plus sometimes you do need to be able to run somewhere for some short distance! (like a couple of city blocks) It's nice to be able to do that without running out of breath so quickly.

All of ten minutes and it's basically free, massive publicity with almost no effort.

Do you think you would've known about this new ISS module if it weren't for Colbert?

This is very true. I still don't like sports and don't play any sports. Not that I wouldn't start in the future if I got into something, but there is absolutely zero athletic skill required to go the gym.

Once I realized that everyone is as self-conscious in a gym as I am, it kinda took a large edge of going to it.

I went to Dick's, purchased some decent looking activewear shorts & shirts, a comfortable sets of shoes, and, bam, now I have been going to the gym, losing weight, having a fine time (listening to music you enjoy helps a lot) AND enjoying looking at myself in the mirror (self confidence booster right there!).

Plus I can tell a girl now I go to the gym, which is maybe a dumb thing, but beforehand, not being able to say that or talk about it was a point of intimidation and a point of lack of confidence. Any girl, and I'm not talking just about the superficial bitches, likes a guy that takes care of himself.

By the way, I am not looking to become buff, just to loose some weight and gain some strength and endurance. I already feel better physically. So what's not to like?

I'm sure I'll look better as time progresses, but that's not my main objective. My motivation is to be stronger and have better endurance, so I can do things without running out of breath so fast, etc. For example, I can go hiking with friends and not fall over on my ass everywhere.

I got my music selection down: drum'n'bass for the treadmill, dubstep for the rowing machine.

I took a geek approach to it. Basically, everything I do has some kind of explanation behind it. Nothing is unscientific. Nothing is "oh this is good for you just because."

Cardio? (Running on the treadmill, bike, rowing machine, etc) -- OK, that keeps your heart running at a high rate (the ranges for those rates are all defined and easy to find... I try to keep mine between 155 and 175), so that your body can burn fat. Makes sense.

Weights and crunches? I am lucky to have a gym at work, and the guy that runs it worked with me on a program that exercises all my muscle groups. I can make numerical progress over time (be able to say lift 5 lbs more here). He explained each exercise and which muscle group it works. It all makes sense.

These are all the things that will give you confidence that you were lacking before. If you have never made it to a gym, give it a shot. Go and make that initial purchase of gym clothing & shoes (like I did)--it gave me a mental investment and that initial kick to go (well I just blew $200, I better go now!). Then when you get there, just get on that treadmill and after 5 minutes of easier walking, turn it up and get sweating. Take a hot shower at home afterwards and you'll be coming back for more.