One of the highlights of Bob Martin’s recent TDD class at Comcast was watching him use tests and a set of transformation patterns to evolve and transform code to eventually achieve its aims. By using a set of refactorings he called Transformations, you not only get to something that works, it will be easier to maintain, modify, and use.
Author Archives: Karl
RIP Dennis Ritchie
Economist.com: “Dennis Ritchie, a father of modern computing, died on October 8th, aged 70”
Tim Bray: “DMR, 1941—2011”
A post to mark the passing of someone not so well known outside of technology, that should be, because so much of what they use today is founded upon his work. We owe so much to him.
Dizzying but invisible depth: on complexity
Jean-Baptiste Queru, on his Google+ profile, posts a poetic and doozy of a post, “Dizzying but invisible depth”:
Today’s computers are so complex that they can only be designed and manufactured with slightly less complex computers. In turn the computers used for the design and manufacture are so complex that they themselves can only be designed and manufactured with slightly less complex computers. You’d have to go through many such loops to get back to a level that could possibly be re-built from scratch.
Once you start to understand how our modern devices work and how they’re created, it’s impossible to not be dizzy about the depth of everything that’s involved, and to not be in awe about the fact that they work at all, when Murphy’s law says that they simply shouldn’t possibly work.
For non-technologists, this is all a black box. That is a great success of technology: all those layers of complexity are entirely hidden and people can use them without even knowing that they exist at all. That is the reason why many people can find computers so frustrating to use: there are so many things that can possibly go wrong that some of them inevitably will, but the complexity goes so deep that it’s impossible for most users to be able to do anything about any error.
Java coder don’t get Lisp? Read defmacro: on coding
Slava Akhmechet wrote a piece a while back that that challenged my thinking in terms of design using an old familiar friend and adversary: Ant. If you are a Java programmer, you’ll recognize the patterns Slava is connecting with to share with you why Lisp is so interesting. BTW, this piece would work doubly well with Maven if it was updated. Go read.
It’s more than just Dart – recent language development: on coding
Michael Fogus reviews the astonishing (to the unfamiliar) number or new programming languages being developed these past 5 years from Scratch to CoffeeScript, to Dart, it is quite a list.
Missing Doctor Who 1: What to Watch: The City of Death
So, you’re fan of the new Doctor Who series and are missing your weekly Doctor Who fix, this post is the start of a series just for you.
There are a lot of posts out there that introduce you to the history of the show that will introduce you to episodes of the old series gently. Feel free to read those I linked. Good stuff.
I’m not going to do that. I’m just going to suggest you watch one episode, maybe a week, with me, that hopefully stands the test of time. These episodes are available online if you have any Google-foo whatsoever. Remember, YouTube isn’t the only place where people post videos daily that have motion.
First in the list is an episode from the 4th, written by Douglas Adams (yes – THAT Douglas Adams!!!) that starts out a little cringe-worthy, but turns into a fun, and interesting story, that just maybe related to the current show in more ways than one (check out that ship for example – look familiar?) – “City of Death”.
Wikipedia: “City of Death”
TARDIS Index File: “City of Death”
Look for it, watch it. Sure there are more important things, but you got to have a little fun.
The Matrix and its influences: on storytelling
Rob Wilson’s project releases its latest, this time on The Matrix, showing its influences inline, including a snippet of the 4th Doctor in “The Deadly Assassin”:
Everything Is A Remix: THE MATRIX from robgwilson.com on Vimeo.
Metrics and damn metrics: on systems
Sometimes we get caught in numbers and miss what’s real. This can happen especially when we focus on the wrong numbers writes Arpit Mathur in a sharp post. I’d add even if you were looking at the right numbers, without context, just like a soundbite, you could derive the wrong lessons or encourage behavior that you didn’t desire.
Always ask: What is it we are trying to effect or learn about? Are we looking at the right things? Do we have the context necessary to understand it?
Related:
“Systems Thinking, Lean and Kanban”: “Creating Useful Measures”
Michael Feathers: Rocky Mountan Ruby 2011 Keynote: “Code Blindness” – fantastic – watch the whole thing.
Impermanence and Software Design: on systems
When you’re building software, it is probably best to look at things half-Buddhist. Kent Beck writes about building software that won’t be around longer than him in a recent Facebook note:
…nothing I am doing now with software will remain in a hundred years. Indeed, there was a time not long ago when the only software I had ever written that was still running was JUnit. Thousands of programs started, and my work was in danger of becoming extinct.
I could try to achieve timelessness in my designs and encourage others to do the same, but in the end nothing I program will outlive me. It would be easy to despair over this, to go into my shell and settle for “good enough”. To do so would be to ignore both the immediate impact of my work, used by hundreds of millions of people today (one of the great things about working at Facebook), and the second order effects of my work on the lives and attitudes of others. No, my programs won’t be here in a century, but my work still matters.
Related:
Michael Mehaffy and Nikos Salingaros: “The Pattern Technology of Christopher Alexander”: “We have to remember that software engineers, by nature of their work, have a big problem. Their job is not to solve problems for computers, but for human beings; the computers are only tools in that process.”
Case Statement: “Articulate Coding” – his first post – a good one – keep it up!
InfoQ: Kent Beck: “Responsive Design” 1hr Presentation. Worth it!
On People, Process, and Passion and Persistence
My boss back at Bell Atlantic, who became my friend and mentor, Pat Trongo, had the following quote from Peter Senge’s “The Fifth Discipline” on his cube wall in big bold letters.
I found it inspirational back then. But now I am blessed to see evidence of this pattern in life daily – Great teams committed to a purpose accomplish great things.
The committed person brings an energy, passion,
and excitement that cannot be generated if you
are only compliant, even genuinely compliant.The committed person doesn’t play by the rules
of the game. He is responsible for the game.If the rules of the game stand in the way of
achieving the vision, he will find ways to change
the rules.A group of people truly committed to a common
vision is an awesome force.They can accomplish the seemingly impossible.
I am as blown away by this as I am with the OccupyPhilly protest teamwork I saw today, as I am with my co-workers who are one of the greatest teams I’ve seen in my career.
Great teams are everything. They don’t just ‘happen’ and require investments in trust, empathy, accountability, honesty, and crazy foolishness to grow. And when you see them you can’t help but be in awe.