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...

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.

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.

I agree. While building the initial product takes time in and of itself, adding features to any project takes an even greater effort IMO.

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.

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...)

"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.

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".

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...

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.

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?

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.

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.

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.

What environment are you doing this in ?

windows, coding PHP.

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

I recall studies that claimed 10 LoC per day - that is, debugged, documented, production, finished code.

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.

I think the estimate is good. When I write 100 LOC, it probably won't be correct the first time. So I go back, fix, test and fix again. While having another look at it I notice that some things can be condensed or replaced with existing code. When I'm done I end up with half the code I started with. So: did I just spend an hour on 100 LOC or 50 LOC?

It seems low at first, but if you factor in debugging and documentation it is actually pretty good. I wished I could claim that as an average. I've pulled all nighters in a familiar environment starting from a 'blank' page where you get this amazing amount of output but that usually slows down quite a bit by the time the week is up.