So much for having del.icio.us links auto-posted. What was I thinking?
If I was able to take link posting frequency down to once per week I might leave it on, but once per day is ruining the look of the blog and spreading the signal amongst the noise more thinly than we’re all used to.
I’ll relegate del.icio.us links to the ever-expanding sidebar at some point.
Comments rss
Trackback Comments rss Trackback(h/t http://paul.kedrosky.com/)
Comments rss Trackback Comments rss Trackback Comments rss TrackbackI have a soft spot for Grady Booch. We knew back in 1993 that he was a hippy, what with all those dotty clouds. Today (you ca see below) he’s still a hippy! A greying, post-heart-surgery, eminent software development guru hippy with a penchant for Halo. It’s a good thing Jacobsen and Rumbaugh set him on the straight and rectangular when they U-ed their respective MLs.
Below is a video embed (courtesy of the YUI Theater) of Grady giving a version of his Turing Lecture “The Promise, the Limits, the Beauty of Software” to an audience at Yahoo!
It’s a heavy sprinkling of software history and a boat-load of personal anecdotes. The anecdotes are especially valuable, as they’re from the perspective of someone who has incredible access to many of the major software development projects and organizations around the world.
It’s jam-packed with golden nuggets of wisdom and fore-warning. Around 8 minutes in he warns about perpetuating organizational silos with (what I’d call) interior-decorator SOA. At 36 minutes he talks about assessing an organization’s maturity through their release frequencies, the presence of a “culture of patterns” and a system or organization. He moves on to Boehm and COCOMO, and the observation that complexity is the dominant determinant of project cost — bad process is something that amplifies the effect of complexity and good process dampens it.
In all, it’s a nice introduction to the how and why of software development and how we got to where we are today.
Comments rss TrackbackI’m a bit of a tinkerer in my leisure time. I like messing around with different software, hardware and writing little programs to try stuff out and keep current with a variety of fun-looking technologies. I also do a little bit of development for friends and family, but mostly this is fun-driven as well. This makes me someone who knows jack about most trades and a master of not so many.
My modus operandi is to prepare list of things to do, and then work through them in an order prioritized by fun and tempered by expense.
It’s like I’ve been running my home leisure time as a consultancy practice with myself as my biggest customer. Although I find tinkering endlessly enjoyable I rarely end up with a finished product because I’m more into the journey than the destination. I’ve been thinking about how much more satisfying tinkering would be if it occasionally resulted in something that was more like the dictionary definition of completion. My inspiration has been a recent post by Marc Andreessen on personal productivity, and a recent re-reading of the PSP and TSP management frameworks.
I remember reading that the most important thing about a consultancy practice (apart from customers) is to have a “pitch-able” methodology and a knowledge base. Inspired by this, I thought I’d create a list of things I think I need to develop a sufficiently documented, scrutinized, and understood “home tinkering” methodology with an emphasis on achieving a collection of finished products. I never thought I’d yearn for efficient leisure time, but there it is, I do.
Getting my home tinkering consultancy practice outlined should help crystallize my random thoughts into more consistent processes than I have now. It also opens it up for improvement through helpful suggestions.
My list of areas to discuss, document and make consistent is currently:
Over time I’ll write a page on each.
Comments rss Trackback Comments rss Trackback Comments rss Trackback Comments rss Trackback Comments rss Trackback Comments rss Trackback
