Code Renaissance is about building great teams and great software. By exploring best practices, team interactions, design, testing and related skills Code Renaissance strives to help you create the team and codebase that you've always wanted.

Its better to be wrong than to be vague

There's a saying, "Its better to be wrong than to be vague". This is apparently credited to physicist Freeman Dyson, though I heard it in a talk by Fred Brooks. I believe this saying holds true in any scientific discipline and especially in software engineering. If you're wrong and specific then others can question your assertions and assumptions; together the group will find the correct answer. It's best for the team and best for the project, but it requires a degree of trust and maturity only found within well-lead, competent, accountable teams.

Guidelines for Communications in Accountable Teams

  • If you don't know just say you don't know... then go find the answer.
  • If you think you know then clearly identify your degree of certainty.
  • If there are other likely causes or possibilities then acknowledge them.
  • In areas where you are knowledgeable be bold enough to take quick, logical, defensible positions; be wise enough to remain silent in areas where you are not.

Audio: Jim Purbrick and Mark Lentczner on Challenges in Second Life Programming

(Recommended Audio - MP3 From

Second Life is a massive persistent 3-D world that has millions of users. Jim Purbrick and Mark Lentczner talk about the programming challenges they face in developing in and for this environment. Regardless of what you think of Second-Life itself, this is a truly intriguing and informative talk.

Talk Index

  • 0:00:00 - Intro / About Second Life
  • 0:18:24 - Problems with internal scripting in second life
  • 0:34:22 - A new approach to internal scripting (really cool stuff here)
  • 0:54:54 - Collaboration, Communication and Teamwork
  • 1:14:33 - Questions

While listening to this my mind turned to the Wayne's World scene where Wayne and Garth are comically bowing to Alice Cooper, chanting "We're not worthy!!! We're not worthy!!!" (Even if you don't get the reference I trust you get the idea). They're programming on a 3D persistent world with 30,000 to 60,000 concurrent users, 15,000 CPUs, and 30 million concurrently running scripts; this is mind-blowingly cool stuff.

I am but a humble business programmer. It's fun and I enjoy it but even at it's very best the cool factor of my work would only reach a 2. It was nice to glimpse through the looking glass and briefly see the world beyond; Follow the white rabbit and all that... perhaps some day I will.

Agile Manifesto

I recently became a signatory of the Agile Manifesto and I wanted to share it with you:

The Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more.

You'll notice that it does not advocate any tools or practices, but simply the driving concepts behind agile processes. Regardless of what you think about Lean/Agile practices, I hope we can all agree that these are solid principles to move towards. If you'd like to become a signatory you can sign up here.

It's always a people problem

There's a saying (credited to Jerry Weinberg) that I've heard drifting around for a while now in various talks, blog posts, and books. Here are some common forms:

  • No matter what they tell you the problem is, it's always a people problem.
  • No matter how it looks at first, it's always a people problem.
  • No matter what the problem is, it's always a people problem.

I believe it was Kent Beck who related the 5 whys (from the Toyota Production System) to this. Basically the premise is that if you ask why roughly 5 times and try to move in the direction of a people problem then you should be able to root out a human cause to the problem. I'd like to take it a step further and say: "Don't stop with 'why'. Don't stop at 5. Keep asking questions till you can fix the problem."

An Example: The deployment failed

  • Why?
    • Users are unable to log in.
  • Why?
    • The application is pointing at the wrong database.
  • Why?
    • The config file had the wrong connection string.
  • Why?
    • The developer changed it for testing and didn't change it back.
  • Why?
    • We don't have a clean process for changing configurations from dev to test to prod.
  • Why?
    • No one has taken the time to create a process.

OK, that's a people problem, but let's go on.

  • Why hasn't anyone created an effective process?
    • We don't have the time.
  • Why?
    • There's to much to do, too many projects, too many fires(like this one), it's just not a priority.
  • Why?, no wait scratch that... who sets the priorities?
    • Management
  • Is anyone talking to management about this?

Yes, no, maybe? Whatever the answer it's still another people problem. Let's continue.

  • Has anything like this happened before?
    • Configuration file problems between dev, test, and prod? Yeah sure. Why?
  • Well wouldn't you have more time if you fixed this process instead of having to debug failed releases all the time?
    • Yeah, but...

We could keep going but you get the point. I think one of the most important skills that anyone can develop is the art of asking effective questions. In addition to helping you root out the causes and fixes for problems, it will also help prevent mistakes that are rooted in preconceptions, misunderstandings, and assumptions.

Audio: Robert Kalin on User Interfaces

(Recommended Audio - MP3 from

This is an entertaining and thought provoking talk by Robert Kalin from the 2006 IDEA (Information: Design, Experience, Access) Conference. Robert discusses the history of Achitectural/Object design concepts and how he is apply them to the User Interfaces Design on the website

Whiteboard appreciation day

There's a Dot Net Rocks Interview with Richard Campbell where he says:

"Computers are amplifiers; they can either amplify our intelligence or they can amplify our stupidity. Until we can clearly delineate what we're trying to achieve on a whiteboard, computers are not going to help us."

I whole-heartedly agree.

I'd like to suggest we start a whiteboard appreciation day. You know, everyone bring a little gift, an eraser, some new dry-erase markers... Treat it to a good cleaning, whatever.

Ok, I'm kidding, but only slightly. I love whiteboards almost as much as I love computers. They let me work out ideas in free and unhindered ways. I often do impromptu sessions, just me and a whiteboard, for small projects, application problems, or designs in need of refactoring.

The next best thing is a free computer-based tool called Freemind (on Sorceforge). It's a mind mapping tool, which is basically a structure-enforced whiteboarding application. It's very useful and I highly recommend you give it a try.

There's always a Trade-off

In Kent Alstad large scale site talk that I recently mentioned he discussed the trade-offs needed to scale large websites (i.e. more complexity, greater cost per feature, etc). It got me to thinking that in Programming / Design / Architecture there's always a trade-off. Even if the trade-off is very small, even if you don't know what it is, there is always a trade-off.

For some reason this also touched off a connection to an old post that Jeff Atwood made about the Worse is Better concept(where Worse is a measurement against an intellectual ideal, and Better refers to the success of a product). He chews on the idea that Complex and Right often looses out to Simple and Wrong. Off the cuff I'd say that worse probably is better, except for all those times when it's not.

New Years Resolution: Can you sleep when the wind blows?

Kent Beck's Call for Accountability in Software Development was for me a call for self-evaluation. Consider the following story he shared:

Once, a farmer interviewed a young man for a job as a farm hand. One thing the young man said particularly puzzled the farmer, “I can sleep when the wind blows.” The farmer didn’t know what this meant, but the young man seemed competent and knowledgeable and so he was hired.

A few months later the farmer was awakened in the middle of the night by a thunderous wind storm. Panicked, he raced to the cot where he found the farm hand fast asleep. Shaking him roughly awake, he demanded, “We have to bring in the animals!” “They are already in.” “We need to fasten the windows.” “They are already fastened.” “We need to tarp the hay.” “It’s done.”

After going down his list of worries and being reassured that they were already taken care of, the farmer finally realized the meaning of the young man’s puzzling statement. By taking care to finish every job and leave the farm safe every night, the farm hand could sleep when the wind blew.

The farmer went back to bed and told his wife what he had just learned. She just smiled knowingly and the two of them went back to sleep, lulled by the music of the storm.

Are you reliable? Are you accountable? Professionally, do you do what you say and say what you mean? Can you sleep when the wind blows?

Audio: Kent Alstad on Large Scale Sites and Application Data Cashing

(Recommended Audio - MP3 from

The talk was given by Kent Alstad at DevConnections, with comments by Richard Campbell and Carl Franklin. The talk begins 10 minutes 40 seconds in. It has alot of excellent information on performance in large scale internet applications and the trade offs of application space data cashing. If you work on internet applications I highly recommend this.