I recently posted on how failure is essential . Along the same lines of failure being essential to learning, conflict is essential to innovation and change. I’ve often felt this. Not everyone feels this way, but I love a healthy debate. Rick Brenner recently published an article in his Chaco Canyon series on this topic, called Teamwork Myths: Conflict. At my last job (Atpima), one of the many wonderful projects I worked on was called TeamBuilder (my name was conveniently left out since I left the company). You can follow that link to read all about it, but the relevant concept is when you’re building teams that need to work on hard problems that may require out-of-the-box solutions, conflict can lead to new solutions. Or at least a thorough review of the pros and cons of the known options. When a team has a well-defined problem and must act quickly, conflict can be bad. Just like tools, you need different ones for different tasks.
This is another “Where the heck did I find this?” link. I bring you Awkward Family Photos. Here’s my favorite. Think twice about breaking up with one of those daughters!
Title: Ken Schwaber on “Flaccid Scrum - A New Pandemic?”
When: Thursday, 06/18/09 06:00 PM - 09:00 PM
Where: MIT Building 26, Room 100, Cambridge, MA - Cambridge
Cost: Free
Scrum has been a very widely adopted Agile process, used for managing such complex work as systems development and development of product releases. When waterfall is no longer in place, however, a lot of long standing habits and dysfunctions have come to light. This is particularly true with Scrum, because transparency is emphasized in Scrum projects.
Some of the dysfunctions include poor quality product and completely inadequate development practices and infrastructure. These arose because the effects of them couldn’t be seen very clearly in a waterfall project. In a Scrum project, the impact of poor quality caused by inadequate practices and tooling are seen in every Sprint.
Ok, that sounds like like a pretty obscure line. But that’s kinda the point. This article from Agile Observations from the Trenches blog. Yeah, it’s an article about Agile software development. But it’s really about accomplishing any goal.
It’s really worth reading the article, but here’s what that title is about: Sometimes you need to accomplish task Foo, but then you realize you first need to accomplish task Bar, and then before Bar you need to do task Baz, and so on. It’s easy to lose sight of the original goal, and then you’re really in trouble.
A fairly religious Jewish friend posted on Facebook today that he “broke a molar eating a shrimp today. Interpretations?” Needless to say the jokes came fast and furious. But along with the jokes came a link to the Got Hates Shrimp website. Pretty clever, if you have good reading comprehension skills and working satire detector.
I’m an officer in the Boston Linux and UNIX group, and have been a member for over a decade. Here are the details of the Wednesday, 06/17 meeting:
Date and Time: Wednesday, June 17, 2009 from 6:30 pm to 9:00 pm
Location: MIT Building E51, Room 315
Presenters: Kurt Keville, SDC Coordinator, MIT Institute for Soldier Nanotechnologies (kkeville alum mit edu) and Brian DeLacey, (bdelacey gmail com)
Kurt Keville, Brian DeLacey and others discuss the 802.11s (Mesh) standard and what it means for embedded Linux distros such as OpenWRT and Robix, the distros of choice for the upcoming local Muniwireless rollouts. Kurt gave earlier talks on Muniwireless at our February 2008 and August 2006 meetings
Note that Brian and Kurt will be holding an all-afternoon pre-meeting, beginning at noon in E51-063. This afternoon session will build a multi-node solar-powered super computer as a clustered web-server using fast flash and Marvell’s SheevaPlugs. Rabeeh Khoury of Marvell will be onsite for lots of Linux and SheevaPlug Q&A. Sage Radachowsky will be showcasing his latest solar circuitry. The working SWARM system will be demonstrated at the main meeting, but anyone is welcome to drop by and pick up a soldering iron or keyboard to work with earlier in the day.
Also, this month is BLU’s 15-year anniversary, and we will be celebrating with a cake at 7:00 PM.
Scientists understand this. If you don’t fail, you don’t learn. But you have to be careful how you define failure. To a Scientist, not getting the results you want is not failure, it’s success. That is, as long as you get reliable, consistent results.
One of my family’s favorite TV shows is MythBusters. Of course, much of what they do is horrible science in the name of entertainment. I’m OK with that. But it certainly gets fun science out there. Adam Savage, one of the two main hosts, recently appeared at Maker Faire (run by Make), where he gave a wonderful talk (video from fora.tv can be found here), mostly on this topic.
This is not a new issue, but I just found out about it from this article on TechRepublic.com (yes, their URL is technrepublic.com.com). They state that Firewire (IEEE 1394), unlike USB, was designed more as an external system bus connection, not just for external storage. That allows Firewire devices to sneak in under the covers and do pretty much whatever they want, waving the “I’m with the band!” badge at any secuirty, including logging into the system.
Since this is part of the design of Firewire, it’s not a bug that can be fixed. You cannot protect against security breach by firewire device and still adhere to the standard. This isn’t to say it’s time to weld a metal plate over your laptop’s Firewire port and a tin foil hat on your head, because this isn’t something that you hear about happening in the wild, even though there’s a program out there to do it.
Someone sent a link to this image, which is real funny, but I can’t find how to get to the parent page. Click on the read on… link to see it.
Read on…
