December 29, 2006
I acquired a Wii two days ago, and now I’m sore all over. Wow. I haven’t been this excited about video games since the original Metroid. Other people have written better reviews than I ever will — I just wanted to let other Wii-endowed folks know they can say “Hi!” by sending me (or the lady) a note on our console: 3402 4700 1845 3070
October 31, 2006
I received an interesting e-mail a few minutes ago — looks like Google bought JotSpot, the company that hosts my wikis. My business more-or-less runs entirely on Google services, so hopefully this will blend right in with the rest of the tools I use on a daily basis.
October 19, 2006
Yesterday, The Wife and I were running errands when we noticed a class of middle schoolers standing in a field near our house. The teacher was fiddling with a 2-liter soda bottle equipped with fins: a class-built water rocket. We watched as they filled it up, pumped it up, and with a cheer, launched it into the sky. It was great — an inexpensive, interactive, and exciting demonstration of physics at work. Instead of falling asleep over a book, these kids were screaming about the joys of Newton’s Third Law.
Now that’s education.
September 8, 2006
Looks like the Washington Post has a writeup of my aunt Kit‘s book about Louisa May Alcott, which should be hitting the shelves on September 12th. Good stuff! The Wife is in Boston for the official book launch and a couple of Red Sox games — I have to say I’m a little jealous.
So, if you’re in or near Concord, Massachusetts, and you’re keen on a rather interesting discussion about Miss Alcott, check out the official launch event:
Tuesday, September 12, 2006, 7:30 pm
Orchard House – Home of the Alcotts
399 Lexington Road
September 3, 2006
Ok, so it’s just a little paragraph on the OregonLive Tech Blog … but it’s kinda neat to see a side project mentioned in the local online paper.
August 14, 2006
Alex Bunardzic responded to my previous post, so it looks like we have a genuine discussion brewing here. Blog to blog isn’t particularly efficient, but efficiency isn’t the point of these sorts of things, is it? So, here’s Alex’s original post, my response is here, his response, and now … here we are.
Alex is correct, that this is an issue of common sense verses counter intuitive methodology. Well, mostly correct — good methodology doesn’t have to be counter intuitive. But that’s just nit picking. Perhaps a more accurate statement is that this is an issue of naive verses educated intuition. Rephrased, I think we’re both headed in the same direction .. if from different angles.
Alex’s example of the intuitive (but poorly educated) stock trader is a perfect example. Naive, eager, and ready to commit to whatever catches his fancy — a recipe for disaster, no doubt. Of course, given extensive training and having worked with successful mentors, the trader’s intuition matures and becomes an incredible asset. The book “Blink” examines the power of intuition in both naive and trained forms; Kathy Sierra and Dan Russell have written about it several times. Intuition (or first impression, or whatever you’d like to call it) can be a very valuable tool, no doubt about it … but it has to be challenged and defended and honed over time to become so.
I guess I just have a hard time trusting plain ol’ common sense as a good justification for action. When someone says “Peat, I think we should take this approach” my first question is … why? “It just seems right” isn’t a good answer, even if that person has informed opinions and a good track record of making correct decisions. Is it an issue of trust? No. It’s simply taking the appropriate time to make sure that we’re doing the right thing.
The key, of course, is appropriate.
Alex goes on to say:
“I’ve seen too many people being enthusiastic about the counter-intuitive, bureaucratic ways of developing software. That approach is almost always amazingly catastrophic.”
And he’s perfectly, 100%, absolutely, correct. Heavy handed practices are largely professed by people who don’t know enough about their responsibilities, or don’t trust the advice of people who do. In trying to cover their asses, they suffocate the creativity and passion required to make good software … and kill the effectiveness of their people and product.
On the other hand, if I simply ask “why?” and challenge the technique in question, two things happen: it becomes a question, and therefore a conversation; and the people who make a decision together feel responsible for it. “Why” breaks the intuitive cycle, but not in a fashion that cripples the process of building software. “Why” builds better software, and better developers. Sometimes asking “why” requires a team to throw out heavy processes … or take them on.
I guess it’s important to frame the conversation within the context of what’s important. As Alex said,
“It’s all relative, you see. The only thing I truly care about is the best results for the end user — a human being paying to use the software.“
Sometimes, that person’s life depends on the software, and consequently a remarkable amount of time and energy should be spent on making the system as robust as possible. Sometimes, it’s just a cute little web app. Regardless — good software is always about the end user.
Anyhow, intuition is just another tool in the box, but it’s the first one we pull out of it. It’s worth investing in a good one, but foolish to depend on it for everything.
August 14, 2006
I completely agree that it takes great developers to produce great code regardless of methodology, and that crap developers produce crap software, even with the best intent.
However, there is a part of Alex’s post that bugs me. He states:
“… no amount of clever gimmickry and prescribed methodologies is going to help us. Only plenty of experience and plenty of common-sense can lead us out of that conundrum.”
Maybe I’m taking this the wrong way, but I don’t think this provides a better answer than the concepts he takes issue with: there are plenty of developers who have plenty of experience, and depend on common sense and intuition to really foul up their projects. “Common sense” is what makes gimmicks and methodologies so appealing!
So, instead of experience and common sense, I think a great developer (or manager) is one who thinks critically about a given scenario, and applies the appropriate techniques to complete it successfully. The solution comes out of critical thought and a large toolbox of techniques, developed through experience and analysis — applying methodologies and determining why they succeeded or failed. Were they incompatible to begin with? Were they a good fit for the development team? What indicators can I look for in my future projects and interactions?
The critical approach takes a lot more work and is decidedly less sexy than appealing to common sense, but it reliably produces the best results, and that’s what we’re shooting for. Right?