Archive for October, 2006

Python at the Java Users Group — Tuesday November 7th

radical_pythonI promise, it’s not your father’s Python presentation. I’ve been invited to talk to the local Java Users group about the things you can do with Python.

I’ve been working on my presentation, and it looks like it should be fun! If you’re in Ann Arbor, and looking for some good clean dynamic language fun, stop on by the AAJUG on Tuesday November 7th.

Json, XML-RPC, SOAP and TurboGears

In the TurboGears book we focused on building web applications, but TurboGears is equally useful for creating web services.

It is remarkably easy to use TurboGears to respond to requests, with JSONified data. TurboGears automatically turns python dictionaries into JSON so you can write something like this:

def hello:
    return dict(title="Some title", body="Some body")

In the above method, If the request comes in from the browser with a tg_format parameter equal to ‘JSON’ the method will return JSON. If not the hello.kid template file will be used to render an HTML response. This means the same method can be used to handle user actions via AJAX or regular HTML, which is particularly handy if your application needs to degrade gracefully when the browser doesn’t support JavaScript.

But, there’s no reason you can’t use JSON and REST as web service type interface. In fact this is now my proffered way to expose “web services.” JSON is lightweight, clean, and has good implementations in multiple languages, and REST is a simple, elegant, and powerful way to organize your requests.

Even thought I prefer JSON and REST, the fact of the matter is that sometimes you need to talk SOAP or XML-RPC — because that’s what the system on the other end talks. This part of TurboGears isn’t as shiny and polished as the JSON story above, but it’s still pretty easy.

You can use TurboZSI to talk SOAP. The documentation could be better, but this is actually pretty cool. You can define

You can write your own XML-RPC Handler in less than 25 lines of code. And there’s a ticket in the TurboGears track system to make using XML-RPC work more like JSON.

There have been some rumblings about polishing all of this up and making Web Services a more integrated part of the TurboGears story. To me that sounds pragmatically wonderful. We shouldn’t stick our noses up and refuse to play when “enterprise” technologies show up.

Sure, there may be a better way, but playing nice means adapting to the people around you. There’s a lot we can learn from Rails, but as far as I’m concerned Rails can keep their “the anti-enterprise framework” rhetoric for themselves.

Instead, TurboGears should be the “easy to use, easy to extend framework” that plays nice with others, and makes the enterprise better and more fun.”

So what is vision?

It’s a shared look at the future, and it is a future filled with hope and promise.

If your future looks bright, make sure your team knows about it. Tell the story of how you achieved all this, thank the people who helped you get there.

If on the other hand your company’s immediate future is bleak you can still encourage vision, but you have to creatively and courageously tell stories. I’ve been through this kind of thing at work, and we did come out stronger.

Unfortunately I can’t tell that story.  Fortunately I thought of an even better story to articulate this idea of vision.

In a country where segregation was the law of the land, and racial hate was rampant Martin Luther King Jr, continued to tell the story of a future where people would no longer be judged by the color of their skin.  He continued to tell these stories in the face of economic hardship, and in under the the constant threat of assassination, and with the memory of attacks on his family still burned deeply into his memory.  It is context that  Martin Luther King Jr. made one of his most powerful speeches to his battle weary friends and followers:

Well, I don’t know what will happen now. We’ve got some difficult days ahead.

But it doesn’t matter with me now. Because I’ve been to the mountaintop…

Like anybody, I would like to live a long life. Longevity has its place. But I’m not concerned about that now. I just want to do God’s will. And He’s allowed me to go up to the mountain. And I’ve looked over. And I’ve seen the promised land. I may not get there with you. But I want you to know tonight, that we, as a people, will get to the promised land.

If you are faced with a Death March style project, the only thing you can do is to hold out a vision for a better future and do everything in your power to make that happen. You can’t ignore the present, you can’t ignore the grueling overtime, the unrealistic deadlines, or the managerial mistakes that got you here — if you do nobody will listen to you, nobody will respect what you have to say.  Instead, you have to demonstrate that you have or can come up with a plan to get out of the desert into the promised land.   Compelling vision begins with the hard truth of today, but holds up an achievable hope for tomorrow.

Automation: Doing the wrong thing — faster!

Automation is like optimization, so I would like to invent a corollary to the Horre’s famous Maxim:

Premature automation is also the root of even more evil

If you spend time and money to optimize the performance of a particular piece of code, it will often become more complex, more difficult to understand, and more costly to change in the future.

The same thing happens when you automate a sales process, or the way you route phone calls. The process becomes less adaptable to change, sub-processes are invented to route around difficulties with the main automated process, and can get crazy.
Sure, you can get things done more quickly. But if you’re customers are routed incorrectly, they don’t care how quickly they get to talk to the wrong person!

And the danger is not just that you’ll get it wrong in the first place, but that you won’t be able to adapt to changes in the environment around you because adaptation would mean throwing out all the work that went into optimizing that process.

Some of this problem is economic.

The cost of automating a process must be repaid quickly for the automation work to be valuable. The exact ROI time is function of how much change happens in that area of your business.

But some of it is psycho-social.

Even if a particular automation project has already paid for itself, the fact that it exists makes the whole organization more likely to resist change, because you don’t want to ‘throw away’ all the hard work that went into automating the old process.

Not only that, if it’s not handled well by management, seeing a project you worked on for months last year being “thrown away” can be seriously demotivating to the automator.

Premature automation is the root of all kinds of evil.

The Agile Story: Show, don’t tell

The other day I was reminded of something I learned in creative writing, and how it applies to talking to people about Agile methodologies.

My professor would tell us “You don’t say, ‘When Jack lost his job, he went a bit crazy’ instead, you show him doing crazy things and let the reader see Jack’s state of mind for herself.”

William Carlos Williams said it another way “No Ideas but in Things.” Concrete things, facts, and images are the hallmarks of a good story. Here’s the Jack/crazy story with the commentary removed and a few details added:

After the layoff Jack drove home parked in the garage, and sat there for over hour. When his wife finally got home from work, she him sitting in silence, in his car, in the dark.

When she knocked on the window, he blinked turned to see where the noise came from, and didn’t even seem to recognize her.

To often we tell people our conclusions about what happened, rather than giving them the right context and the right images.

We tell them how Test Driven Development will increase their productivity, but we don’t give them the stories that show how it will make them feel more confidence and less stress.

The preface of Test Driven Development by example is a good example of what I’m looking for. Kent Beck tells a story about two days in the life of a programming team, and what Test Driven Development (TDD) did for them. I read this book 3 years ago, and I don’t remember much of the specific advice Kent gave in the book, but I do remember the story of Ward Cunningham, and the team of developers who saved the day.

A well told story is about organizing the right details in the right order. And people only change the stories they play in their heads when you offer them a better, more engaging story. If you’re trying to lead a team of people to try incremental delivery, or test driven development, weekly code reviews, or some other new technique, your best shot is not to tell them it’s better, but to tell a story where somebody they can identify with used that technique to solve a problem.

If you do this right, you’ll give the other person the privilege of saying “hey, why don’t we try that here.” Then, suddenly they own the idea, and you’re just a willing and encouraging partner. This is a lot better than fighting with the team “in their best interests.”