Geeks and non-geeks alike should do their research when buying electronic devices to make sure they can actually do what they want, and don’t have unacceptable attributes. In this post I’ll give some examples, and some helpful guidelines.
I’ve been focusing on change a lot lately. Thankfully, not because of my day job this time. This time, it’s more to do with one of the not-for-profit groups I’m involved with. A couple of other things have planted this bug in my ear, though. Someone I know told me about the book Switch: How to Change Things When Change Is Hard, which is a fantastic book (so far. I just got my own copy and am reading it now). The other thing that got me thinking was an episode of Anthony Bourdain: No Reservations I saw recently. More on both of those later. The message I want to throw out there is that you can often achieve much better progress making small changes you can make today instead of waiting until there’s buy-in, resources, and removal of obstacles to a much larger effort. And those smaller changes are likely to have more direct beneficial effect, because contrary to what large corporations like to think, big changes often introduce larger problems. I have always tried to do this in my personal life and at work, and try to get others to do the same.
As a creative person (and as a geek), when building something (software or hardware), I often say to myself “For just a little more time and/or effort, I can add this cool feature.” There are many good reasons why this is a bad idea. I would like to lead with the reason that has caused my blog to be stagnant for months, which is that doing more than you have to gets in the way of actually finishing. An artist I almost knew once said “The hard part about painting, is not the painting, but knowing when to stop.”
Since my last post, I’ve started about six posts that I never finished because I just wanted to add this one last point, or tweak that paragraph one more time. The result was no visible work output, which is inexcusable for an Agilista. Read on…
I’ve been using Linux/UNIX for about 20 years. I am also Assistant Director of the Boston Linux and UNIX Group, and have contributed to several open source products. In general, I find open source software more flexible, more transparent (no security through obscurity), and more focused on what’s needed instead of what marketing says would be cool. I like that open source software is usually developed modularly, with separate components each doing what they do well, each designed to be combined with other component, each with its inputs and outputs documented for fitting Tab A into Slot B. Open source’s community support model (with a sufficiently large community) is often far superior to calling tech support. All that said, I still believe very strongly in “the right tool for the job”. Sometimes open source is not the answer.
Just like commercial software, it’s important to evaluate not only how well the software suits your need, but the “health” of the product and its creators. Just because it’s still available doesn’t mean it’s still supported, updated, and in common use. That may not be a deal-breaker for you, but it does need to be factored in to the decision.
As a Software Engineer, I normally think of Agile in terms of software development. As someone who has rolled out Agile practices at several companies, I also think of it in terms of how Agile software development affects the rest of the company. The last company I worked for (yes, I’m still looking for work!) implemented full Scrum, including pair programming, TDD (as in, insufficient code coverage had a direct effect on your bonus), retrospectives, standups, etc.
I came across an interesting blog post, The Smart Entrepreneur’s Guide to Finishing What You Started, on Scott Ginsberg‘s blog that suggests entrepreneurs learn lessons from Agile, too. Scott bills himself as “The Authority on Approachability”, but most of his blog posts seem to be aimed at high-level business and marketing people. He also claims to wear a nametag 24/7, with a tattoo of a nametag sufficing for certain occasions. Everyone needs a shtick, though, and this is what us geeks call “mostly harmless“.
This post proposes favoring action over inaction, moving at a sustainable rate, making sure you’re focused on the customer’s needs, limiting scope to enable completion of a phase/project, and [post="Done Means Done Done Done" text="making sure done means done done done"]. Sound familiar?
I also liked his post 6 Ways to Rally without Being Ready, reminding us that you’re never 100% ready, but that’s not actually required to start.
Today’s lesson for hardware people, software people, architects, and mad scientists is brought to you by Ray Bradbury in the form of a short story called There Will Come Soft Rains. I recommend you follow this link and read a copy of the story, as it’s only a few pages long, and well done (but I already said it was Ray Bradbury, didn’t I?). The story, written in 1950, takes place in 2026 in a very modern, fully automated house, with all sorts of computers keeping its occupants fed, cleaned, entertained, and on schedule for work, school, and play.
Only there are no more occupants. Because there was a nuclear war, and they’re all ashes. The house (the last house standing), in it’s quite-less-than-infinite wisdom, has not caught on to this. So it prepares eggs and pancakes for breakfast, and provides entertainment in the nursery, and defends itself from the few birds and animals that may approach it, and fleets of mechanical robots diligently clean up any dirt that gets in the house and dispose of the uneaten food. In short, this system has insufficient connection to the world it interfaces with, and too few checks on expected responses, to know that something is horribly wrong.