Professionalism in Python or: How To Not Bankrupt Your Company, Ruin The Python Language, and Make Children Cry

Recently, I wrote a blog post about Python Quality, that got some comments and spurred an offline discussion with David Beazley. (As a side note, he has written one of the best Python books ever in "Essential Python Reference".) One of the things he brought to my attention was an excellent presentation by Robert Martin at RailsConf 09, entitled "What Killed Smalltalk Could Kill Ruby, Too".

You can watch the full presentation here, and I highly recommend that you watch it, perhaps even right now, you can always come back to my blog post. I was nodding my head the whole time, and thoroughly enjoyed the both the message, and the great public speaking by Robert Martin.

The author's main conclusions about how to save Ruby, are directly transferable to "saving" Python. The key word, if there is one, is professionalism. According to Robert, "Professionalism: The disciplined wielding of power". When there is professionalism, these three areas are being addressed:

1. Discipline: specifically in test driven development.
2. Humility: The us versus them attitude.
3. Acceptance of solving the dirty problems.

First, let's dive into his point about Discipline. Ultimately writing quality code, with tests comes down to a "being lazy" problem, or an ignorance problem. If it is an ignorance problem, which is quite prevalent when a language's community grows quickly, then it may be as simple as dealing with, as Jeff Atwood refers, "The Non-Programming Programmer". You can expect 199 out of 200 people applying for a job might be NPP, but there are some ways to deal with that in an effective hiring process (I have a another blog post I am writing that talks about my take on the technical hiring process).

If it is a being lazy, then that is inexcusable. Of course, in general, as a programmer it is good to be lazy, but the right kind of lazy. Robert brings up this analogy, "It is the discipline of the doctor who washes his hands when he leaves one patient and goes to the next". My take on that is if you are employed as a professional Python software developer, then not writing tests is lazy, unprofessional, and unacceptable…period.

He goes on to say some things that other people like Titus and Grig have been saying for a long, long time, I think their faces have actually turned blue a few times too. To avoid making their faces Avatar blue, I will quote Robert this time, "If that batch of tests can be run at a click of a button, how afraid are you to clean up a mess that you found somebody left in the code….Nothing makes a system more flexible then a suite of tests……If you have a terrific design, but not tests, you will still be afraid(to fix bad code)."

Tests are important, and easy ways to run the tests are important. My preferred workflow at this point, is to have Hudson run unit tests, functional tests, test coverage analysis, and code metrics. I have all of this wrapped into a custom test runner I wrote in anger one day, that counts bad metrics as a failure, as well as unit test failure.

The next thing he brings up was humility. This is a very interesting point, and I will directly quote him: "There was an arrogance in the smalltalk community that told them they were better…it was a powerful language and they knew they could work miracles….Our tools are so good, our language is so good, we don't have to follow the rules."

I love this point. Getting past the obvious first stopping point, which is according to the Dunning-Kruger effect, the dumb guys are the most confident, and the smart guys are the most insecure, there are some other interesting things to consider. Writing understandable code is very hard work, and an act of humility and, ultimately, skill. Robert mentioned that Ward Cunnigham's idea of "clean code", was that it was obvious what a function did. This isn't as easy as it sounds. In fact, this is a lot of hard work, even with a language as beautiful, and elegant as Python.

What I see too often in some Python code is trickery, arrogance, and needless complication. For example, useless multiple inheritance, nesting classes inside of functions, "pure" functional programming dogma, or tricks for the sake of tricks. Sometimes these things are warranted, but having the restraint to understand, as Robert puts it, "Powerful tools kill quickly, and in surprising ways, and we are going to be careful.... " Often in a failed or troubled Python project, you will see a lot of code where someone was making a mess by trying to be cute. In a successful project, you will observe where immense effort went into making code that is obvious and understandable.

In addition, arrogance can also come in other forms, such as dogmatic adherence to a library or framework. There are many different libraries and frameworks in Python, one size doesn't fit all, and often it is a matter of saying "It depends…". This is why I wish recruiters were a bit smarter about putting vanilla framework buzzwords in their job postings, because it often encourages the arrogant Python programmer to apply. And in addition, when I ask the companies technical questions, that buzzword framework was used, but is often now a hybrid solution, or has been replaced by something not as buzzword friendly.

Finally, he mentioned acceptance of solving the dirty problems. This is a really interesting, and valid thought. In particular, he mentioned schemas. Having worked on some truly awful schemas, I concur. Any library or framework that expects a greenfield is going to have some big problems in the enterprise. They may be very successful on a new project at an enterprise, but that is why it is important to have diversity in libraries and frameworks and to keep our humility in check. For example, SQLAlchemy, with SQLSoup is a really powerful way to tap right into a scary legacy database and be productive from day one, but it isn't red hot buzz worthy, and is not in all of the San Francisco startup job postings.

In conclusion, Python is a scalable (even for gigantic projects), elegant, powerful, and productive language, but like any powerful tool, it depends on the skill and professionalism of its operators. In the wrong hands, unprofessional developers could use Python to bankrupt a company, just look at the film industry, they are a poster child for unprofessional Python development. I wonder how much money it would take to make a film if the software didn't suck so much and constantly need to be fixed by scores of people working overtime. Hopefully the people at the very top who count the beans will pay attention to the fact that professionalism is the key to profitability with Python.