PyCarolina Redux

We just wrapped up the inaugural PyCarolinas conference. I know I had a good time and it was great to see so many people in attendance not only from the southeast, but from across the US with even some international attendees.


Professor Gary Bishop of the Department of Computer Science at UNC Chapel Hill gave our first keynote on Saturday touching on accessibility and enabling technologies. It was an inspiring call to action. We as developers have tremendous power at our fingertips to make a difference in the lives of countless individuals around the world. Just do it and make it happen. Leave the committees out of it.

Lynn Root gave Sunday’s keynote, where she shared her experiences in joining and building communities. My favorite take away here on the simplicity of community and solidarity was, “Hey! You’re a nerd. I’m a nerd. Let’s hang out. Kthbai.”

Barry Peddycord III’s talk about Python in computer science education sparked a lot of offline discussion, which struck close to home given some of the educational technology initiatives I’m working on.

I missed Michael DeHaan’s talk on Ansible, but it did put it on my radar. While, I’ve made healthy use of Chef, Puppet, (and fabric), they’ve never felt just right and I would gladly jump ship to a better solution. So, I hope to check it out in the next few days.

I was cursing Fred Alger after his talk, Sysadmining Python to the Moon, for planting the seed that maybe I could build something and send it to the edge of space–it’s possible. Just what I need. It was a fun, inspiring talk and while I hope I can shake its effects, I have a feeling I may be revisiting it. You can check out his presentation materials over on github.

François Dion gave a fun and passionate talk about Raspberry Pis, their use in exciting kids, and how to seriously soup them up with all sorts of add-ons. I plan on following his work over at his Raspberry-Python blog.

David Ray and Julia Elman from Caktus also had great talks about working with designers, which sparked some good discussion. David presented django-comps, which looks like a simple, yet handy tool for serving a directory of static-y html files from a Django project. The idea is you can have a designer work within the same source repo as the project proper as they start building out comps/templates. This is an ideal setup for integrated rapid prototyping. Your project’s defined comps directory will show a list view of the available pages from which you can drill down. You can also easily zip things up for delivery to a client for offline review. I’m looking forward to checking this one out.

Another nice nugget came care of a lightning talk given by Simeon Franklin (@simeonfranklin). If you find yourself using optparse: stop. No really. Check out docopt. It looks like it may take a tremendous amount of pain out of writing command line utilities.

I think the first PyCarolinas event went swimmingly. A huge thanks to Calvin Spealman, Chris Calloway, UNC, the PSF, all the volunteers and the sponsors for making it happen. I’m already looking forward to next year’s!

PyCarolinas Attendees
PyCarolinas Attendees

Python Hack Night #3

We had a good turn out for TriZPUG’s third Python Hack Night tonight. All in all, nine local pythonistas showed up at MetaMetrics in Durham and dug right in. There was good conversation and it seems like progress was made on most fronts. We had a wide range of projects including: personal websites, a scrum workflow tool, a computational teaching problem, a game project, a nose plugin, a Django-based charting framework, and more. We even had an impromptu game AI-building competition emerge.

I was pleased with the results and would love to see one at least once a month. Let’s see what August brings.

Python + Django vs. C# + ASP.NET: Productivity Showdown

People are often asking me how and why my department shifted from an ASP.NET environment to Django. I’ve finally gotten around to writing about the process leading up to our decision. I hope people out there find it useful in their own development groups and discussions.

Almost two years ago I was in a rather unlikely situation in that I was running a software engineering department containing both a C# team and a Python team. The Python group was focused on building scientific computing and NLP-type applications, whereas the C# team was focused on building web applications.

A few of us Python folks in the department had already started playing around with Django–building internal web applications and projects outside of work. It did not take long for us to realize the power of Django and how quickly we were able to produce high-quality applications with little effort. This was my (strong) impression, but in order to propose a corporate platform shift I was going to need some data to support my claims.

It slowly dawned on me that I had a perfect test bed. Here we had two teams using different technology stacks within the same department. The same department. That means they shared the same development processes, project management tools, quality control measures, defect management processes. Everything was the same between these groups except for the technologies. Perfect! So like any good manager I turned my teams into unwitting guinea pigs.

The Hypothesis

We can accomplish more with Python + Django than with C# + ASP.NET given the same amount of time without sacrificing quality

Measuring Productivity

For the sake of this study, I defined productivity as a normalized team velocity: how many story points were completed / developer / week. I record the normalized team velocity for each team’s sprint for later analysis.

For those of you unfamiliar with the concept story points I highly recommend Mike Cohn’s Agile Estimation and Planning.

WAIT! You can’t compare story points between teams!

I hear this a lot. Yes, you can. The problem is that most people do not bother creating a common scale or continually calibrate their estimations (within or between groups). Generally, it’s way more work than most groups need to deal with and it doesn’t deliver much utility to most groups so it isn’t often discussed or practiced.

The methods described below should outline the additional calibration work that was performed to ensure a common estimation scale between the two teams.


Both teams continued business as usual working on projects in parallel. Each sprint consisted of 3-4 developers. It is worth noting that Team ASP.NET did not make use of MS MVC Framework, but they did use Linq-to-SQL for its ORMy powers.

Special care was taken to maintain linkage between the two team’s effort estimates. During sprint planning, each team would use a common story point calibration reference when making estimates. In order to detect any potential deviations in calibration, during several planning poker sessions I included stories that had already been estimated during previous sprints or by the other team; no significant deviations were found.

At the end of each sprint I would calculate the normalized developer velocity ( # of completed story points / developer / week ). These values were recorded for both teams. It should be noted that only Django-based sprints were used in analysis for Team Python.

I recorded results for approximately 6 months.


Django ASP Histo

Normalized Developer Velocities: C# + ASP.NET and Python + Django

The above histogram shows the distribution of normalized velocities associated with each completed sprint. The table below summarizes the distribution of velocities associated each team.

Summary statistics of each team’s normalized developer velocities

Units: story points / developer / weekC#/ASP.NETPython/Django

The distribution of velocities between the two samples are similarly shaped, but have clear differences in their mean. The average velocity of a C#/ASP.NET developer was found to be 5.8 story points/week. A Python/Django developer has an average velocity of 11.6 story points/week. Independent t-tests reveal these differences as being statistically significant (t(15) = 4.19, p<7.8e-4).

Discussions and Conclusion

Given our development processes we found the average productivity of a single Django developer to be equivalent to the output generated by two C# ASP.NET developers. Given equal-sized teams, Django allowed our developers to be twice as productive as our ASP.NET team.

I suspect these results may actually reflect a lower bound of the productivity differences. It should be noted that about half of the Team Python developers, while fluent in Python, had not used Django before. They quickly learned Django, but it is possible this fluency disparity may have caused an unintended bias in results–handicapping overall Django velocity.


The productivity differences quantified by our findings were then included as part of an overall rationale to shift web-based development platforms. Along with overall velocity differences, the costs associated with maintaining each environment were considered: OS licensing and database licensing for development and production environments, as well as costs associated with development tools. I’m happy to say we are now a Python and Django shop.


Several good questions over at Hacker News