2. Set up a development environment and deploy the code there. Get it working. With code that large (and with the added wrinkle of executing code out of the database) changing things is going to be a nightmare of unintended consequences. Getting a testable environment up will let you find those things and help you understand what it does.
3. Get it in version control. This should be number 1: Before you make changes get a baseline of where it was.
4. Find a bug that exemplifies the nastiness of the whole situation and make a fuss. Let everybody know why this bug is so bad and what caused it. This will give your employer a concrete example to look at when you say "this code is shite". Harp on this bug.
5. Fix that one bug. Roll it out. Be a hero.
At this point you'll have a good base line, some credibility, and the organization will understand what a mess they've got. Now you'll have to figure out what you want to accomplish: keep it limping along? Improve it? Rewrite? The above steps will get your feet under you.
I read your comment as: Brand building advertising is under priced because people think it can't be tracked.
My point was once it can be tracked well it will come to light that it's not very valuable. Because that's the pattern we've seen with online display.
But, as I reread your comment I realize that I'm thinking TV style mass broadcast advertising here, and if you mean branding advertising on online platforms then I agree with you that in that context it's under priced.
> they are willing to pay extra for things they think they can track.
> This means that if I'm right (and who knows) then the brand-building advertising,
> that most people consider largely untrackable, is underpriced.
I disagree. Online display advertising, which can be tracked effectively has had incredible downward pressure on prices as tracking has gotten better.
I think most advertising is highly overpriced (brand advertising especially) and as tracking gets better prices will drop.
Ad supported business models get harder and harder in that world.
The article kind of glossed over this, but the Click through rate of .55% is off the charts. It's _clearly_ fraud, based on having seen thousands of ad campaigns data. Anything over .1 is great, and over .2 you start looking for what you broke.
.55 is an Adops executive daydream.
(The .059% from UK visitors is about what you'd expect)
It depends how you approach the problem. I'm guessing here, from my own experience implementing social graph features, but here goes:
There are a couple of ways you can go about this, the first is the database: Join the network of people against the land of content and bring it back. This doesn't work (as an aside this is what people mean when they say web scale, it has nothing to do with web traffic, it's social graphs) your database will cry. All though not at first, in development it works fine, and you feel fine, and for a while you're ok, but you start growing....
Another way you can go about it is by denormalizing. In this world you store a pointer to each content item for each user. So anytime I do something all the people [following|watch|connected|friended] to me get a record indicating I did this. This works, but now you have lots of data (lots and lots of data!) spread all crazy around. You need some kind of system to push that data out to everybody. It's those last two that drive up your hardware usage, it's not necessarily web boxes, but it's boxes in the background broadcasting the events out to the world, and the datastores to hold it all. Depending on how your web code works you could also have a lot of overhead on the webservers putting all that stuff together.
My experience here comes from building the social features into toolbox.com. A good example is this page http://it.toolbox.com/people/george_krautzel/posts-connectio... That's all the posts from users connected to our CEO (all 750k of them). Getting that to return in near real time is super fun (and you can probably tell that I went down the DB join path before it all fell apart).
2. Set up a development environment and deploy the code there. Get it working. With code that large (and with the added wrinkle of executing code out of the database) changing things is going to be a nightmare of unintended consequences. Getting a testable environment up will let you find those things and help you understand what it does.
3. Get it in version control. This should be number 1: Before you make changes get a baseline of where it was.
4. Find a bug that exemplifies the nastiness of the whole situation and make a fuss. Let everybody know why this bug is so bad and what caused it. This will give your employer a concrete example to look at when you say "this code is shite". Harp on this bug.
5. Fix that one bug. Roll it out. Be a hero.
At this point you'll have a good base line, some credibility, and the organization will understand what a mess they've got. Now you'll have to figure out what you want to accomplish: keep it limping along? Improve it? Rewrite? The above steps will get your feet under you.