Technology ADD – On Django and Python

I seem to be suffering from a form of ADD recently. Hopefully it’s not the kind I’ll need Ritalin for although I haven’t actually checked with a doctor yet. But this is a special kind of ADD, technology ADD.

After living a lifetime stuck in a bit of a technology trap, using what everyone else seemed to be using and what recruiters wanted to see on your CV I’ve suddenly been opened up to a world of promising technologies. In the past month I’ve not only carried on writing in Ruby on Rails but have also started using Django, a full on web framework which is powered by Python.

A lot of people, my previous self included, would tend to call these new web frameworks lightweight and not suitable for really serious applications. I still haven’t quite made my mind up if this statement holds any merit but maybe a better question would be does the application you are working on have to be “serious” anyway. By serious here I mean seriously built. Does it need to scale horizontally at the flick of a switch, will you be dealing with billion row tables and processing 6,000 requests a second? They’ll probably answer that one day they might. That’s true, although only if they manage to launch without sucking up their funds building a project in a serious fashion.

Case in point about two years ago I tried a personal project in Java. Java’s what I know best so it seemed a sensible option. Professionally I work on a robust codebase with a great Spring / Hibernate base, full on integration testing, custom authentication code and a beautiful Ant based build environment. But I also forgot that the environment took 5 smart people 2 months to set up. Admittedly I now knew the general setup but it was hard work being disciplined and trying to write so much from scratch, in my SPARE TIME. The initial setup must have taken 6 months. I had lost all enthusiasm for it by that point.

Two weeks ago I started a project in Django. I didn’t even know Python. In a week of spare time work I’ve got a fully working database model, authentication framework, frontend with templating. I’d estimate I might have spent about the same time drawing pretty pictures for the frontend as writing backend code. That is truly astounding. I was impressed with Ruby on Rails but this is another level. Webapps can be coded in less time than it would take you to draw a UML diagram or database hierarchy.

The best thing is it has brought back my enthusiasm and hopes for personal projects. When writing something in your spare time, the best thing you can do is finish something. Don’t obsess over perfect theoretical programming practices, scalability and how you’re going to track sessions across multiple servers when you haven’t even got something launched. Obviously if you’ve got £1,000,000 and know your app is going to be huge, build everything as well as you can. For the rest of us I’d suggest speed is the more important factor.

Simplicity and Polish

I’ve recently bought a new 24″ iMac after many years using a PC as my main computer and occasionally begrudgingly using a “permanently borrowed” Mac laptop from my girlfriend. The new screen is certainly a sight to behold and has increased my productivity no end. I’m definitely not an avid gamer but one thing I am surprised is the lack of commercial games available for the Mac.

Before we take this tangent too far, the reason I mention it is because I’ve been trying out a few online Flash based games. Miniclip has tons of them, from flying a stunt plane to parking cars. But the place I always end up back at is WinterBells. The salient thought behind this post is that simplicity, or rather polished simplicity is an admirable target. While the games at miniclip are certainly impressive and flash (pun intended), the one I enjoy playing most is Winterbells. From a programmer’s perspective Winterbells looks simple, almost trivial, but there is literally nothing I can fault about it.

Let me explain. I think there is a tendency for application development to naturally descend into including everything and the kitchen sink. Business types are keen to include everything to see what shit sticks, development are probably thinking about showing off and working on fun technologies. Maybe taking a step back and focusing on what is important in your application; making that fantastic and giving sufficient time to polish it would be a better approach. That takes real work though, I have noticed recently that oftentimes over 50% of a project is taken up not in building something that works, but building something that is brilliant.

Take thepickuptruck as an example. I would say I wrote the bulk of the code, i.e. the database model, controllers and Twitter hashtag retrieval methods in a couple of nights maximum! Especially with some of the newer languages and frameworks, you can build something that works in a trivially small amout of time. It was tempting to think there wasn’t much left to do, but in fact the hardest bit was refining the app to feel finished and professional. The only word I can think of to truly describe this is polish. A good application should feel nice to use, smooth and polished. The chasm between something working and working well is huge, and truly separates the genius from the rest.

The lessons I have learnt (or am learning) are that focus is key, pick what you want to work and make sure you are totally happy with it. Approach suggestions for extra features with extreme skeptiscm, and if they are deemed important, plan for time not just to make them work but to make them shine.