A Django website that took (a lot) more than 20 minutes.
lukeplant.me.uk
lukeplant.me.uk
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...
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.
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.
You have to think about things such as adding a new feature which works well with the rest of the site, add the new code without making a mess, change the existing implementation of a feature 'cause you realize your first implementation was not the best way to do it, or that it does not work so well with the new feature etc.
All this time and effort should be counted in - putting out an initial release is good, but you still have a lot of work left to do.
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...)
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.
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".
This is something I keep fighting against myself on, but it makes my code more portable...
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.
But in an hours coding I'd hope to push 100 LOC.
"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.
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.
You can see the code in entirety too when I get back from Holiday :)
The odd thing was that it was 10 LoC whether it was assembly or high-level languages - because you could do more in 10 lines of a high level language, it is actually more productive. Not really surprising, I guess; that's the point of good abstractions.