Matt at Signal vs. Noise:
“Studies show it doesn’t matter whether you ask people for their realistic best guess or a hoped-for best case scenario. Either way, they give you the best case scenario. It’s true on a big scale and it’s true on a small scale too.”
This is a fascinating new site that really sheds some like on where all our federal spending is going. Check out the Government’s IT Dashboard. You can’t fix what you don’t measure!
Life Clever on Why design is political:
“Some problems cannot be solved,
because stake-holders cannot agree on the definition.”
It’s a quick read, and worth taking the time.
Why, you ask, does Peter continue to ramble on and on and on about Agile? What is Agile? Why does he care?
Let me tell you a bit about this, my latest, crazy esoteric interests.
Agile Software Development is about approaching software development, better. It was founded with the Agile Manifesto, and has some pretty solid principles behind it.
My interest has been heightened of late because I’m on the planning committee for this years conference. I can’t say I’m planning per se, as I joined the group late in the game. Most everything was already planned. I am really just there to helping out with bits and parts on their web site, and occasionally I’m contributing to some of the marketing. It’s way geeky of me, but I’m really excited about the conference, and I’m absolutely jazzed to be helping out in any capacity. I wanted to go a number of years ago, but it never worked out.
I’m also excited about Agile in part, because I’ve been burned too many times by environments that follow ideals that are rather the opposite. Having had a fair bit of software development experience, what I’ve seen over and over again is that the “items on the right” (see the Manifesto) are often crutches for people. And bad crutches at that. These people tend to not understand technology and want safety nets to give them the sense that a particular software development project is stable, secure, is making progress, and is bound to succeed. Focusing on those “right” items, in my mind, only lead to a false sense of security. It obscures the fact that when focusing on “contract negotiation” you’re not really collaborating with your customer or when focusing on “comprehensive documentation,” you aren’t building anything yet – just describing it. It’s sorta like writting a 200-page document that simply describes the book you are about to write. It just doesn’t make a lot of sense.
In software development, the only measure of progress, the only way to be sure that something useful is being created, is to have actual, executable, functioning, working code. Not prototypes, not wireframes, certainly not design documents … only working code.
I know. Crazy esoteric interests.
Thanks goes out to Nancy & Christy for inquiring, and spurring me on to actually explain it.
I run into this same problem:
“The problem is that abundant resources, like computing power, are too often treated as scarce. Consider another example: Wired‘s IT department used to send out occasional emails telling employees it was time to “delete unneeded files from the shared folders”—their way of saying they had run out of storage room on the servers. [...] One day, after years of this ritual, I began to wonder just how much storage capacity we actually had. Turns out, not so much: 500 gigabytes. At the time, a terabyte of memory (1,000 gigabytes) cost about $130. I had recently purchased a standard Dell desktop PC for my family, which the kids used for playing videogames; it came with a terabyte internal hard drive. My children had twice as much storage as my entire staff.” (emphasis added)
I find that simply pointing out the absurdity of it doesn’t seem to “fix” the issue. Any advice on how to help people see that they are treating an abundant resource as if it was scarce?
Read more at: Tech Is Too Cheap to Meter: It’s Time to Manage for Abundance, Not Scarcity
monthly email
RSS 2.0