
A Django website that took (a lot) more than 20 minutes. - jacquesm
http://lukeplant.me.uk/blog.php?id=1107301641
======
MichaelApproved
I'm so sick of hearing how apps and websites were built overnight. I'm a
programmer and I know just how much work goes into building a site and all its
little details.

There's a great Mixergy interview about how Digg wasn't built in a day either.
Owen Byrne, the guy who built the original Digg site, talks about how much
work it really took.

[http://mixergy.com/pr-lies-destroy-your-understanding-of-
how...](http://mixergy.com/pr-lies-destroy-your-understanding-of-how-business-
really-works-owen-byrne-digg/)

~~~
bad_user
What usually happens is that the programmers think about the project long
before starting to work on it. I have 3 ideas that at some point I'll start
implementing, and right now I'm gathering bits and pieces of information for
all three.

And when it comes the time to do it, the core functionality can be done really
fast if you have good tools, since you are prepared for it.

What separates the good projects from the bad ones though are final touches
and the features that are expected by the users - those weird business logic
additions that aren't properly defined. These take an incredibly long time to
do. Not to mention deployment and scaling which is always a fun ride.

And of course, there's always that intern/junior that has to work on
something, and he's given the task of helping you, leaving a mess in any
module he touches ... and then you have to clean-up the code, just to keep
your sanity.

~~~
MichaelApproved
Oh it's the business logic that drives me crazy. Lets face it, most web code
is ABC simple, rarely is there innovation in web code.

Show this, hide that. Click this, open with ... a fade. ABC

It's the business rules that each line of code is trying to accommodate that
takes the longest to work out. Thinking out the ripple effects on the future
is the time killer.

------
patio11
This is an interesting breakdown of technical debt as you'd actually see it in
a real, production site. Crufty systems to rip out and replace with
frameworks, databases which were being shared across applications, data
migration (I feel your pain), etc.

On the plus side, after you get good at using a framework, you tend to
accumulate a lot less debt. The downside is that your first project with a
framework probably incurs more debt than you would otherwise, although if
"otherwise" is a using a home-brewed flat-file DB you might come out net
positive anyhow. ;)

I've ripped out almost 70% of the code that was in the first commit for the
Rails version of the Bingo Card Creator over the years. (I did not know you
could serialize an array in the database, so instead, I wrote it to a ...
home-brewed flat-file DB...)

------
boundlessdreamz
"I'm quite pleased with my results! I'm not sure if I can really give a less
biased view. I normally find with programming that by the time I've finished a
project, I'm already quite unhappy with the quality of the code, and I have a
list of 'cleanup' TODOs, or even 'rewrite this large chunk of it' TODOs, which
usually never get done. By the time a few years have passed, I'm downright
ashamed. So far I don't feel this way about any of the code -- let's see how
long that lasts!"

This is exactly how i feel most of the time. When I look back at my code which
was written a year back, I think it is downright ugly. Sometimes I feel I
haven't learned enough. I should be able able to write clean code which will
remain clean. Other times I feel that it is a good sign that I'm feeling this
way because that means that I have learnt something over the period and i'm
constantly learning.

------
10ren
I've been writing a series of experimental prototypes recently; and I've
noticed that as I try to add things to an existing prototype (instead of
starting something new), it becomes incredibly painful. I actually end up
spending almost all the effort on trying to make it fit with the code I've
already written.

Reusing code seemed like a sensible thing to try to do (you should reuse
code!), and the existing code itself was actually pretty clean - just not
designed for what I wanted to do next.

Therefore, I've decided in future to try out making prototypes that are
_strictly_ prototypes. If I want to try something new, I'll make an entirely
new prototype. And see how that goes. At the very least, it will probably be
more fun. :-)

I mention this here, because of the article's description of "honeymoon code"
vs. "maintainable code".

~~~
blhack
You need to make your functions smaller and more generic...

This is something I keep fighting against myself on, but it makes my code more
portable...

~~~
jacquesm
Making them generic is key to code reuse, smaller is sometimes only to improve
readability.

As soon as you see a pattern appear in your code, something idiomatic that
you've done a couple of time with small variations it's high time to abstract
out a library function.

Do that a couple of times and you'll see the size of your functions diminish
as if by magic.

------
jknupp
This article was written 3 years ago. I'm guessing Django has improved quite a
bit since then. Maybe this would have been a bit easier if done today?

------
ErrantX
I do think his estimate of 30/40 LOC is low - though perhaps he means an
average over the "life" of a project.

But in an hours coding I'd hope to push 100 LOC.

~~~
pvg
It's not 'perhaps what he means', it's one of the central points of his
article. He doesn't 'perhaps mean' it, he spells it outright -

"I've spent a total of 240 hours on the project, or about 6 working weeks."
This is his total time, coding, or otherwise.

"In terms of code there are about 2000 lines of template code, 6000 lines of
Python, and 900 lines of migration scripts (done in Python). [...] Given those
figures, it looks like I was reasonably productive -- averaging over the
complete time that comes to about 37 LOC/hour, which is reasonable."

I.e. 8900 LoC / 240 hours = 37.08 LoC/hr. That's 37.08 LoC/hr where hr is hr
of total time spent on the project.

His estimate is low if perhaps you'd read the article.

~~~
ErrantX
That still seems incredibly low (and yes I did read and I still think it's
low).

Picking the most recent example from my projects..

This project has lasted 2 weeks so far (12 days). About 15 hours according to
my commit logs - so that is roughly 24 hours work including debugging. It's
almost feature complete (I reckon another 5 hours total to release it).

After I scrap all the js libraries and all my drop-in code the lines I have
written in that time comes out as 4940.

That's 205(ish) LOC per hour.

So, yes, his is a low figure (though my figure is easily the maximum I can
manage - this was a productive project; I would say 100 is my average)

EDIT: I will agree with his stuff about honey moon period. I would say the
bulk of that code came out in the first 10 hours. Half of the code was written
on wednesday in a 5 hour coding session (and 3 hrs of debugging).

Perhaps it is to do with how I work and the fact I am well practiced in this
language & framework. I sit and write code solidly for 3 or 4 hours. Then
spend and hour debugging all that code - that is a good workflow for me but I
know others hate that approach! (we regularly argue over it in the office :P)

If you read he learnt a lot of things as he went along - and include them in
the metric. So that lowers the value somewhat. If your working with code your
well practiced in and using a framework to build on then it's definitely a lot
faster.

The main point I was making is his metric seems bad - and the value he comes
out with very low. As he bases his whole point on it I think it weakens his
fairly good argument.

That said I know a couple of programmers who could slam out and debug a 6000
line web app in a long weekend; and it would mostly work.

~~~
jacquesm
What environment are you doing this in ?

~~~
ErrantX
windows, coding PHP.

You can see the code in entirety too when I get back from Holiday :)

