Children of kings and great magnates were the first to grow up out of touch with the world. Suburbia means half the population can live like kings….

Paul Graham

You can’t shelter people from everything bad or scary, and expect them to live in the real world.

Project managers, System Administrators, and parents should take note of this.

People can only step up and take responsibility when they actually know what’s going on. Seems to me that there are lesions for how we talk to people about project risks, how we handle e-mail spam problems, and how we think about IT services. It’ll be a while before I figure out what exactly all of those lesions are….

Data is certainly not like many other assets, it doesn’t depreciate, you can copy it endlessly, and it’s next to impossible to imagine a commodities market for data. Heck copying the data can either increase it’s value (think “The DaVinchi Code”) or decrease it (think passwords). People don’t pay for data as much as they pay for human attention. You can use data to get attention or you can use attention to collate, assimilate, and otherwise transform raw data into useful information, but either way data needs people to understand and interpret it to become valuable.

So at best:

data + human_understanding == value

Bruce Schenier takes it one step further, calling data the pollution of the the information age.

Data Pollution

Data sucks up space, time and human attention. But more than that, data can be parsed, manipulated, and transformed to fit various agendas. And in a world where data about all of us is “owned” by various large corporations, from Amazon, to Google, to Enron, it’s not always clear how that data will be used. Besides which millions of credit card numbers are stolen from various companies who store our data “in good faith.” Data costs money in terms of maintenance, in terms of storage, and in terms of liability. Heck, I know people who work for companies who have an e-mail retention policy — which is really more of a mandatory e-mail deletion policy.

Polluted Data

And that assumes that all that data is verifiable true, and that’s definitely not the case. I sold a car once and the new owner didn’t take it to the DMV to get it registered before his friend drove it without a license and got it impounded. And that showed up on my credit report for years. I have a friend who somehow ended up “deceased” even though she’s still very much alive and well.

All of this is to say that as software developers, IT Mangers, and companies in general need to think a lot more about data, and to invest in some better terms for the various different things we call data.

We need to differentiate between raw data, information, and knowledge. We need to help our customers think about the life cycle of the data they want us to capture. We need to educate people about the costs and benefits associated with keeping data, and ultimately we need to follow the mantra:

Think before you store

And if you’re concerned about privacy, and individual liberty, please take a few min and read Bruce’s article.

Unfortunately multi-process and the JVM are currently two tastes that don’t taste great together. You can do it, but it’s not the kind of thing you want to do too much. So, the Jruby guys had a problem — Rail’s scalability story is only multi-process (rails core is NOT thread safe), and Java’s not so good that that….

Solution: Running “multiple isolated execution environments” in a single java process.

I think that’s a neat hack. The JRuby team is to be congratulated in making this work. It lets Rails mix multi-process concurrency with multi-threaded concurrency, if only on the JVM. But it’s likely to incur some memory bloat, so it’s probably not as good as it would be if Rails itself were to become threadsafe.

I’m not sure that the Jython folks have done anything like this. And I’m not sure they should. It’s a solution python folks don’t really have. Django used to have some thread-safety issues, but those have been worked out on some level. While the Django people aren’t promising anything about thread safety, it seems that there are enough people using it in a multi-threaded environment to notice if anything’s not working right.

At the same time, TurboGears has been threadsafe, from the beginning, as has Pylons, Zope, and many other python web dev tools. The point is, you have good web-framework options, without resorting to multiple python environments in one JVM.

Why you actually want multi-threaded execution…

In TurboGears we’ve found that the combination of both multi-threaded and multi-process concurrency works significantly better than either one would alone. This allows us to use threads to maximize the throughput of one process up to the point where python’s interpreter lock becomes the bottleneck, and use multi-processing to scale beyond that point, and to provide additional system redundancy.

A multi threaded system is particularly important for people who use Windows, which makes multi-process computing much more memory intensive than it needs to be. As my Grandma always said Windows “can’t fork worth a damn.” ;)

But, given how hard multi-threaded computing can be to get right TurboGears and related projects work hard to keep our threads isolated and not manipulate any shared resources across threads. So, really it’s kinda like shared-memory optimized micro-processes running inside larger OS level processes, and that makes multi-threaded applications a lot more reasonable to wrap your brain around. Once you start down the path of lock managment the non-deterministic character of the system can quickly overwhelm your brain.

As far as i can see, the same would be true for a Ruby web server in Ruby 1.9, where there is both OS level thread support and an interpreter lock.

I’m well aware of the fact that stackless, twisted, and Nginx have proved that there are other (asynchronous) methods that can easily outperform the multi-threaded+multi-process model throughput/concurrency per unit of server hardware. The async model requires thinking about the problem space pretty differently, so it’s not a drop in replacement, but for some problems async is definitely the way to go.

Anyway, hats off to the Jruby team, and here’s hoping that Rails itself becomes threadsafe at some point in the future.

Why have motivational meetings?

The right way to use motivational meetings is to reaffirm the purposes of the group, and help people to connect the dots between their individual efforts and the collective goals of the group, and to connect those goals with their own individual aspirations.

Basically, motivating people is easy:

• Give them work that is meaningful to them and to the organization
• Treat them with respect

Treating people with respect includes paying them a fair wage, and not doing any of these things.

Among other things it also means not letting people who aren’t contributing to the common goals of the organization hold back the group by not doing their job.

Research has shown that one of the survey questions most highly correlated with motivation and performance is:

Does my supervisor, or someone at work, seem to care about me as a person?

Which is another way of saying does your boss respect you. At the same time the single highest correlation for any question was:

I get to do what I do best everyday at work.

So, it’s really important to line people’s intrisic skills and internal long-term motivational drivers with the work you ask them to do.

If you’re not doing those two things, motivational meetings are a loss. If you are doing them you can use a meeting to remind people of how their deeper motivations are connected to what they are doing now.

P.S. My info on the top questions and their correlation to performance comes from Gallop research via the very interesting book First Break All the Rules, which is one of the best, and most evidence based, books on managing for exceptional performance I’ve read.

Motivation is a complex network of hopes, dreams, fears, needs, frustrations, incentives, and personal morality. Motivating people is as much about connecting their individual aspirations to the goals of the organization as anything. If people can do what’s right, become who they want to be, and get paid to do it, that’s a far more powerful motivator than you can get from any meeting.

If those things are true, you can skip the motivational meeting. Everybody would rather sit down and get some work done. And if they aren’t true it’s not likely that another meeting will help.

What is Ruby 1.9? Do we have a spec? A test suite? Anything? If the answer is no, it’s not ready.

–Charels Nutter (in a comment here)

Partly that’s because Charels wants 1.9 as a reference implementation — not just usable interpreter.

But, that highlights one of the reasons I like the way python is developed. There is a test suite, there is a reasnably complete set of specifications. So, from here, it looks like Python 3 is a lot “more done” than Ruby 1.9. But that’s OK, they are both way more done that Perl 6. ;)

I’m still looking forward to Ruby 1.9, and python 3.0.

Clark Ching recently blogged about something I’ve seen a couple of times. He worked for a company that paid developers very well. You’d think that would be good for morale, but it wasn’t. Clark puts it this way:

It was horrible. Everyone who worked there agreed.

People who hated their jobs stayed just because of the money. This meant that everybody had to work with people who hated being there, and that meant that nobody wanted to be there ;)

Good pay reduces turnover, which is generally a good thing. But some turnover is good turnover, so too much pay can actually hurt you. Beyond that great pay keeps people around, but bad experiences with managers and coworkers can do more to kill morale than you can ever replace with money.

The long and short of it is that you can’t paper over morale problems with money, and you can’t fix them by instilling a sense of urgency. Paul Graham suggests one solution — do something good. If you’re doing something good for the world people want to help you. I’d extend that to say if you’re building something people can be proud of, you’re far more likely to create the kind of positive morale which lasts through hard times.

Case in point, this story of a couple of apple employees worked on the graphing calculator that was shipped with the original Macintosh computer. The interesting part is not that they were excited to work on the project, but that they kept working on it under-cover for months and months after they had been laid off.

Why would they do that?

I had long been proud of the elegance and simplicity of our design…. I had designed it for all users, even those who know little about computers and hate math.

I wanted to make mathematics as easy and enjoyable as playing a game.

They did because they were proud of what they’d done, and because they wanted to make mathematics more accessible.

Python get’s a very positive review:

Today you’d be nuts not to look seriously at PHP, Python, and Ruby.

So, the rise of the so-called scripting languages is one of the inflection points, but it’s not the only one.

He singles out web-framework development as one place where there’s a lot of stuff happening, and a lot of new “rails-like” frameworks are cropping up all the time. TurboGears will live or die in the context of a much larger web-development revolution, and we need to be prepared to make our way forward in the midst of that.

What comes after rails will not be a rails clone. It will learn the right lessons from rails, avoid the pitfalls of rails, but it will also need to carve out something new and better than rails. For RDBMS users, I think the key difference between TG and Rails is the power and flexibility of SQLAlchemy. We need to “sell” this better.

There are a lot of other revolutions coming according to Tim. And I do think we’re looking at big changes in terms of everything from programming language choice, to web-development tools, to end-user desktops, and data persistence mechanisms. We’re also just beginning to see what the world of high-end javascript and other “rich” internet applications is going to do to our view of end-user software.

He doesn’t even mention the rise of EC2 and the Google App Engine as sea-changes in the way we buy computational resources, and I think that’s going to have a huge impact.

In the end my prediction is that the way we develop applications will change more in the next 5 years than it did in the last 5, and it’s time to start getting our heads wrapped around these issues, or we’ll be left behind.

The cool thing about this is that we get to share the stuff that makes sense to share, and yet maintain a backwards compatable API. We started a project (authority) which did the same thing, all on our own, but it’s much better to be able to share. ;) The Authority project turned out to provide a lot of useful bits and pieces which have since found homes, and that process will likely continue.

I’ve said before that I’m very impressed with the work that the Repoze folks have been doing, but I think this is a particularly good example of how it’s possible to collaborate in interesting new ways on top of a shared set of interfaces.

There’s a lot more to be done to make python web development work better, and I’m excited because we continue to move towards a world where innovating in one area doesn’t require building a whole new stack.

I think there are big benefits for users of having a healthy and diverse ecosystem.

If stress is a weed, urgency is the seed.

–Jason Fried

Just the other day a project manager I know asked me how she can “instill a sense of urgency” in her team. She wants to get more done, and get it done faster. Increasing developer productivity is a laudable goal. And she is being asked by internal and external customers for more and more stuff.

But I think there’s something wrong with the question. Urgency and “time pressure” are viewed as tools which can increase productivity, and it does work — in the short term.

In the long term motivation, tools, skills, and processes along with things like good unit test coverage, and good “architecture” determine productivity. Constant urgency, looming deadlines (particularly if they are artificial), and constant pressure actually hurt motivation, remove the slack required for building good tools, discourage process improvements, and create all kinds of technical debt. This debt can be measured in terms of decreased test coverage, and “short-cut” coding techneques which undermine good architectural choices.

To put it more bluntly, urgency often produces short term results at the expense of long-term productivity.

If you push a little bit, as I did with my friend, you will usually find that the problem is not a lack of urgency, it’s a lack of motivation. Motivating people is hard, and if they have been burned out by too much “urgency” it just gets harder.

I’ve done it too. But now-days when I hear people pushing a “sense of urgency” I take it as an opportunity to start looking for deeper motivation issues.

But, in spite of 30 years, and thousands of pages written, people still don’t get it.

Up until Monday I was working on a suite of fantastic applications for patient data and hospital management. I was part of a small, but very talented team of developers doing amazing things. Sure we had great tools like Python, Ext.js, TurboGears, etc. But the fundamental reason we were so successful is that we had a great team that worked together really well.

How do you know you’ve got a great team?

Chad Fowler’s very good (but very poorly titled) book My Job Went to India: and all I got was this book has a chapter explaining how before he became a programmer he was a musician, and someone gave him this powerful advice:

“Always try to be the worst player in the band.”

If you seek out people who are better than you, people who will push you — people who will make you grow just to keep up — you won’t have the option of stagnating. You either get better, or you get out. That’s how I felt on this team, and I know it’s how we all felt.

We knew each-other, knew our strengths and weaknesses, and we knew that together we could make things happen. We knew how to challenge one another, and if something went wrong, we would take action to fix it as a team.

Great teams are a huge asset

I can honestly say that it was the best team of people I’ve ever worked with, and we were producing products with real revenue attached — in other words, we were making money, and lots of it.

But as you can probably guess, after the acquisition came layoffs. And the team was chopped in half. Even though the team consisted of the best developers in the company, even though we were the most profitable part of the company, even though things were going amazingly well in our little corner of the world — we were still torn asunder by layoffs.

There may be some higher corporate logic behind this. And perhaps at some level it was the right thing to do, though I doubt it. I am convinced that Lister and Demarco are right is arguing (via peopleware) that a “jelled team” is an incredibly valuable resource for a company. They get stuff done, and get it done quickly, because they already know how to work together well. We cared about one another, cared about our work, and cared about our company, we were motivated, skilled, and we got things done. Loosing that is loosing a lot.

I got lucky

I was fortunate enough to be the newest member of the team, and was one of the folks that was let go. Why fortunate? Because I don’t have to sit around every day trying to get stuff done without the rest of the team, because I don’t have to be reminded every single day of what once was, but is no more.

And because I can take this opportunity to take a breath, look around and try to find a job which fits my long term goals. I don’t know exactly what I want to do yet, but I do know that I want to do something good for python, something good for the world, and something where I get to work with great people.

So if you’re interested, feel free to drop me an e-mail (mark.mchristensen@gmail.com).

Please hire these guys — they are amazing!

But more importantly there are some other great developers who are also looking for jobs. I’ve seen them perform miracles in C#, Java, Python, and any number of other languages. And I know them well enough to know that they would each be a huge asset to any company who’s looking to develop a great team.

One of the things you need the most in team development is someone who has a picture of how it could be better, of what’s possible, and the will to make it so. In addition to their technical skills, I know that’s something they all have. So, if you’re looking for one or more highly skilled software developers in the Atlanta area (or you’re willing to work with remote people) I can’t recommend them highly enough. Please send me e-mail if you’re interested and I’ll pass the info on to the right people.

The goal of the Google Summer of Code project is to get students more involved in the Open Source community, and I’m very excited about getting to know this group of students better, and seeing them show their stuff. And of course I’m looking forward to all the things they promise to do, from building automated build and test systems, to creating a super-easy CRUD interface builder, and improving the performance of Genshi templates.

We also had a large number of student proposals which weren’t accepted for the GSoC project, some of which were very, very good. The competition was very tough this year, and I am hopeful that some of those students will get involved in the TurboGears community anyway.

• DBSprockets User Interface by Alberto Valverde González
• Documentation Production System by Bruno José de Moreaes Melo
• Genshi optimization & XPath rewrite by Marcin Kurczych
• ToscaWidgets Library for OpenLayers and jQuery by Sanjiv Singh
• Improving TurboGears2 support on Jython by Ariane Paola Gomes
• TurboGears Quality Assurance Initiative by Steven Mohr

As you can see the majority of these projects are about improving stuff that’s used in TurboGears, but are generally useful tools on their own. We’re committed to principle of re-usable components, and the GSoC proposals we received have shown that there are a lot of other people commited to that same approach.

I’m particularly interested in Stephen Mohr’s project, because I think having a reliable build and test system available so that we can easily determine if a change in one of our dependencies breaks things is critical in for a world of interconnected but independent components to be viable.

But most of all I’m very excited that Google chose us to participate and that we had such a great set of proposals to choose from. Thanks Google! and thanks everybody who wrote a proposal.

For me nosetests seems to be by far the most run command on my system — I guess that means I’ve been infected the testing meme as well.


ramoth:mramm markramm$ history|awk '{a[$2]++} END{for(i in a){printf “%5d\t%s\n”,a[i],i}}’|sort -rn|head

169 nosetests
52 ls
48 cd
31 Python
27 sphinx-build
27 bzr
20 svn
17 hg
15 ping
11 easy_install


Also I’ve been working on TurboGears 2 docs, and I’m loving sphinx. I also note that 6 of the items on the list are python, and 3 of them are version control systems that I use to manage python code. I expected svn to come in a lot higher, but I reallized that this list is has been influenced by the fact that i use QuickSilver to launch my text editor, and I have been using the svn plug-in a lot.

Zed did a bunch of hacking and came up with this:

http://www.zedshaw.com/projects/zapps/idiopidae.html

Which has a very simple syntax for importing code into your plain-text documentation file. It’s a simple parser that we use to parse the document source and the export files, create parse trees, and do a bit of simple processing. One of the main advantages of this for book writers is that you can have the source code imported into your plain text documentation automatically, and repeatedly. That means you can look at the code while you’re writing. The final parsed output will allow you to convert the plain text document into your final output format (HTML, LaTeX, or whatever) and it will use pygments to code formating/colorization, and interlieve the code into the rendered document.

I also learned that the tool being used to do the new Python 2.6/3.0 documentation has been cleaned up and released as a general purpose documentation tool. It’s ReST (ReStructured Text) all the way, which seems to be a small price to pay for such attractive docs, and such a wide feature set. It also relies on imports from specific line numbers — which is a lot more fragile than marking sections for import, but does not require you to be able to include delimiters in your source code files.

I haven’t had a chance to use it yet, but I’m very excited about it as a tool for the TurboGears online Documentation.

Hooray for better doc tools!

With that said, there is one project being sponsored by the TG team which I want to highlight because I really want to see get picked up by talented and motivated student. The first would be the Genshi speedup stuff, this is going to require some python profiling and optimization skills (obviously with lots of mentor help) and will likely require some C coding as well. But it will be a huge benift not just to TurboGears, but also to Trac, and all kinds of other Python projects which want to produce XML output for whatever reason. Recent benchmarks have shown that TG2 is very fast when you don’t use genshi match templates — so making this stuff faster will have a big performance impact.

So if you’re a student, and interested in doing something challenging, interesting, and useful, please take a look at this, and the rest of our GSoC ideas on the wiki — and feel free to suggest new things on the mailing list.