Do you work (as a developer) at an advertising agency?



  • I do, and I have noticed that software development is done on a per project basis and cost is purely based on hours spent creating and developing per project. Each project is different and usually has a tight deadline. That is because most of the projects are part of campaigns which have a fixed startdate (due to other parts of the campaign like TV-commercials).

    I have noticed that due to the nature of our work, code quality suffers. Most of our customers are happy, because in our industry looks count, and we create great looking sites/banners/webapps/swfs. But when you take a good look at the code it's a mess. Developers don't get time to create high quality code, so you get all the usual anti-patterns and hard to refactor code. Now normally that's not a problem. But often we sell the same _concept_ again to a different customer (or the same customer). And then we expect the code to magically now be amenable to change, which it's not because that was never a requirement.

    The result: a huge technical debt and impossible estimations.

    Anyone have the same experience? Is this a know 'industry' problem and if so, where can I find some good literature or research into alternate methods of cost vs time estimation?

    Thanks!



  • It's not just advertising work that gets done like this, I'm in BPO (business process outsourcing, basically we will run part of your business for you) and things tend to work the same way around here (minus the looking good part).  As for how to correct your estimations maybe it's just a matter of practice, after a bit you get a general feel for what you should tell customers (which doesn't stop you from being off by an order of magnitude occasionally, but it's not common).



  • Yep, 90% of shops I have worked at operate in this manner.  Some places have been so bad as to have different people working on the *exact same product* to go off in their own directions and design/implement the same functionality in wildy different ways.  I think it has to do with dysfuntion in management.  They don't understand and/or trust the technical side of the house, and railroad work through. They only see numbers on paper and have no concept of creating a wuality, sustainable product.  These guys typically also do not view software developers as a valuable asset and high turnover rates only exacerbate the problem.  

    In these shops, you'll hear conversations between J. Random Developer and P.M. Shithead that go like this:

    "Hey we already developed an address form, with validation for a past project, why can't we just reuse it here?"  

    "If you can't get this done the way I say, I'll walk you out and get someone in here who can!"  

    I've heard that threat in various forms more than a few times.

     

     

    --EDIT:

     This would be where I would put on my "Scrum Evangelist" hat... I have worked at a couple of very large companies on pure scrum teams that were able to estimate velocity with frightening accuracy.  Most folks here don't like agile processes because they think it means "hurry up and produce shit code" but that's not what it means at all.  Estimation is a bit of a dark art and in my experience scrum helps with this dramatically. Not everyone is able to be productive on a scrum team though. You must be honest about task progress in the early sprints.  Ego will get in the way, as well as emotional attachment to code.


  • Considered Harmful

    My last job was at an agency. I loved the culture, but the workload and demands were awful, with tons of unpaid overtime.

    Never again.



  • @CaptainCaveman said:

    In these shops, you'll hear conversations between J. Random Developer and P.M. Shithead that go like this:

    "Hey we already developed an address form, with validation for a past project, why can't we just reuse it here?"  


    "If you can't get this done the way I say, I'll walk you out and get someone in here who can!"  

    Ideally it should have been "Hey we already developed an address form, with validation for a past project, I am going to re-use that (unless there is a valid technocal reason) or I can just go grab my hat...."

    ps: 100% on target with your comments about Agile/Scrum.



  • I work for a company that's an advertising agency, but I'm in analytics, not producing creatives. I pretty much work at my own pace, when I'm given assignments at all. The analytics product I do all the tech work for has ups and downs, and currently it's waaay down-- there's only 4 live sites. So I'm writing a Twitter attitude app so we can stop paying "Red Pentagon" $$$ for their crummy product. After that, I'll finish up a few features for our survey product. After that I'll... I dunno. Rewrite the analytics JS again?

    Anyway. "Work for an agency" doesn't mean "work on creatives". If you're stressed-out, transfer to analytics or some other part of the company that probably desperately needs developers.



  • Well actually, what I'm seeing is more that reusability is never a requirement due to time constraints but that an agency has a tendency to sell previous work as a concept to new clients (GOOD!), but then makes the mistake to think that the previous work can be reused (BAD!)

    And how would you apply scrum if the team members work on 3 projects in a week on average, and projects only last 2 weeks? That way you can neither have sprints nor backlogs. What is a single sprint in scrum is a complete project in most agencies.

    All that undermines the ability to estimate time, unless you start defining everything in terms like:

    'A WordPress site, with [n] pages, module A, module B and module C'

    But I can already see the next project where it is assumed that module A can easily integrate with SharePoint and module B can also double as an ecommerce module, all of which throws the baseline estimation off.



  • @locallunatic said:

    It's not just advertising work that gets done like this, I'm in BPO (business process outsourcing, basically we will run part of your business for you) and things tend to work the same way around here (minus the looking good part).  As for how to correct your estimations maybe it's just a matter of practice, after a bit you get a general feel for what you should tell customers (which doesn't stop you from being off by an order of magnitude occasionally, but it's not common).

    I'm guessing lots of smaller projects? How is reusability of the code?



  • @random0xff said:

    Well actually, what I'm seeing is more that reusability is never a requirement due to time constraints but that an agency has a tendency to sell previous work as a concept to new clients (GOOD!), but then makes the mistake to think that the previous work can be reused (BAD!)

    And how would you apply scrum if the team members work on 3 projects in a week on average, and projects only last 2 weeks? That way you can neither have sprints nor backlogs. What is a single sprint in scrum is a complete project in most agencies.

    All that undermines the ability to estimate time, unless you start defining everything in terms like:

    'A WordPress site, with [n] pages, module A, module B and module C'

    But I can already see the next project where it is assumed that module A can easily integrate with SharePoint and module B can also double as an ecommerce module, all of which throws the baseline estimation off.

     

     

    In your case then scrum probably wouldn't work.  You still need something to help triangulate and size tasks though.  What seems most difficult here is:  you keep track of minute details of integrating Module A with Wordpress,  and those details do not apply at all to Sharepoint.  The Sharepoint estimate is foreign territory with regards to Module A, but maybe you integrated Module 7B with Sharepoint, so that could be a starting point?  Of course, if you integrate module A with sharepoint, keep track of everything necessary while you are working, keep track of all caveats and unforseen difficulties, and next time 'round you can use that to help form a baseline.  That all sounds like a pain in the ass.... sounds like the kind of environment where estimations really don't matter.  What matters is that some amount of work gets done by some date no matter what.  Why estimate? 

     



  • @random0xff said:

    I do, and I have noticed that software development is done on a per project basis and cost is purely based on hours spent creating and developing per project. Each project is different and usually has a tight deadline. That is because most of the projects are part of campaigns which have a fixed startdate (due to other parts of the campaign like TV-commercials).

    I have noticed that due to the nature of our work, code quality suffers. Most of our customers are happy, because in our industry looks count, and we create great looking sites/banners/webapps/swfs. But when you take a good look at the code it's a mess. Developers don't get time to create high quality code, so you get all the usual anti-patterns and hard to refactor code. Now normally that's not a problem. But often we sell the same _concept_ again to a different customer (or the same customer). And then we expect the code to magically now be amenable to change, which it's not because that was never a requirement.

    The result: a huge technical debt and impossible estimations.

    Anyone have the same experience? Is this a know 'industry' problem and if so, where can I find some good literature or research into alternate methods of cost vs time estimation?

    Thanks!

    Does it really matter? What's the average usage span of a banner ad, a few weeks, maybe a month or two at the absolute most? Strikes me as one of those things where, if it works, it works, get it out the door and let's move on to something else.


  • @random0xff said:

    I'm guessing lots of smaller projects? How is reusability of the code?
     

    Yes to lots of small projects. Reusability is a little different for the stuff I do as it's normally more of a question of maintainability as those little projects are update this thingy to also handle this similar kind of work or update thingy1 and thingy2 to account for a new business rule.

     

     @CaptainCaveman said:

    What matters is that some amount of work gets done by some date no matter what.  Why estimate?

    My guess would be billing the customer based on estimates.



  • @CaptainCaveman said:

    sounds like the kind of environment where estimations really don't matter.  What matters is that some amount of work gets done by some date no matter what.  Why estimate? 

     

    Because that is the way we put a price on what we do:

    Customer wants a site with feature x and y? That'll take us 16 hours for the design, 10 to create a master page, 4 hours per extra page, 10 hours for feature x, 8 for feature y, 2 hours to setup, 6 hours for testing, 8 hour project management: total cost is hours x rate.

    But then it turns out that feature x is really difficult, because of ?unforseen? and it turns into 4 days work and no way to make any profit on the project.



  • @Master Chief said:

    Does it really matter? What's the average usage span of a banner ad, a few weeks, maybe a month or two at the absolute most? Strikes me as one of those things where, if it works, it works, get it out the door and let's move on to something else.

    Correct assumption, for a banner ad. But that's not all an agency does, some projects are small mini sites with a (usually custom) CMS, built on a really tight deadline with no reusability in mind. For that as well it's no problem to get it out the door and move on.

    But then it comes back for modifications (which were never part of the original functional spec), and that happens again (under tight time constraints). And then the concept is sold to another client. That is where I see incorrect assumptions, namely that the code is now somehow reusable because the concept was reusable (ie. another client could be sold on the idea).

    So much different way of working compared to a shop that only builds a few well-defined products and keep updating them based on a clear roadmap.



  • @random0xff said:

    I do, and I have noticed that software development is done on a per project basis and cost is purely based on hours spent creating and developing per project.
     

    I'm not a developer but I see this in the areas I work (testing and software implementation).  We do the work, creating what we need along the way and when we move on we start again.

    The desire to change needs management approval (as they will have to wear an additional cost for developing reusable IP) and not just the people who do the work.  For that you need managers with a bit of vision so they can see that time spent now will be recouped time and again on future projects.

    Is it possible for you to incrementally make things better?  I.e. On the next project make one part reusable/configurable/whatever...



  • @RTapeLoadingError said:

    Is it possible for you to incrementally make things better?  I.e. On the next project make one part reusable/configurable/whatever...

    That is the biggest challenge I am facing. Rewrite or refactor? With a rewrite it is implied that it's only done when it meets the specs again, and it is a good moment to redefine the specs if necessary. With a refactor, your will need multiple iterations which you may not get.

    I read yesterday in Code Complete (still my favorite book) about internal and external quality of software. I think we're often in a business that only sees the external quality and doesn't realise the value of internal quality.



  • @RTapeLoadingError said:

    The desire to change needs management approval (as they will have to wear an additional cost for developing reusable IP) and not just the people who do the work.  For that you need managers with a bit of vision so they can see that time spent now will be recouped time and again on future projects.

    It wouldn't surprise me if there is little or no interest in doing such things. The cost of developing the reusable IP would be something that they can't charge to a particular client or on a particular job, so therefore is a loss to the company, but the reduced hours per job means less to bill on each job which means reduced income - which might make your account managers look bad because it looks like they're bringing in less business, assuming that their bonuses and reputation are based on amount invoiced rather than overall profitability. (Yes, that's probably TRWTF - but measuring gross amount billed is a lot easier and argument-free than on net profitability where indirect costs are harder to attribute.) So doing things more efficiently might make it harder for them to replace their 2010 BMW with a 2011 BMW.

     



  • @Paddles said:

    @RTapeLoadingError said:

    The desire to change needs management approval (as they will have to wear an additional cost for developing reusable IP) and not just the people who do the work.  For that you need managers with a bit of vision so they can see that time spent now will be recouped time and again on future projects.

    It wouldn't surprise me if there is little or no interest in doing such things. The cost of developing the reusable IP would be something that they can't charge to a particular client or on a particular job, so therefore is a loss to the company, but the reduced hours per job means less to bill on each job which means reduced income - which might make your account managers look bad because it looks like they're bringing in less business, assuming that their bonuses and reputation are based on amount invoiced rather than overall profitability.

     

    A possible benefit is that if we can quote less time for a job (because of reusable IP) we become more competitive and therefore, hopefully, win more work.

     

    Where I work we are really pushing to improve this side of the business - we've spent a fair amount of time talking but we're actually doing something about it now.



  • @RTapeLoadingError said:

    A possible benefit is that if we can quote less time for a job (because of reusable IP) we become more competitive and therefore, hopefully, win more work.

    We are losing work because of this: we are too expensive for some clients. Some things (like simple Flash games/simulations) take us 1-2 days that the boss reckons we should be able to pump out in 15 minutes!



  • @random0xff said:

    Correct assumption, for a banner ad. But that's not all an agency does, some projects are small mini sites with a (usually custom) CMS, built on a really tight deadline with no reusability in mind. For that as well it's no problem to get it out the door and move on.

    But then it comes back for modifications (which were never part of the original functional spec), and that happens again (under tight time constraints). And then the concept is sold to another client. That is where I see incorrect assumptions, namely that the code is now somehow reusable because the concept was reusable (ie. another client could be sold on the idea).

    So much different way of working compared to a shop that only builds a few well-defined products and keep updating them based on a clear roadmap.

    Ah, quite so. You made it sound like most of the stuff you worked on was just little ad pieces, not full blown websites.


  • How does one create good looking single white females? I'm...umm..asking for a friend.



  • @SQLDave said:

    How does one create good looking single white females? I'm...umm..asking for a friend.

    It depends on your codebase and your language, but if they are correctly defined then you simply instantiate the object



  • @SQLDave said:

    How does one create good looking single white females? I'm...umm..asking for a friend.
    I have a method, but it takes 16 years and 9 months at a minimum...



  • @intertravel said:

    I have a method, but it takes 16 years and 9 months at a minimum...
     

    Can't you just get some people to help you? I need this by next week.



  • @Paddles said:

    It wouldn't surprise me if there is little or no interest in doing such things. The cost of developing the reusable IP would be something that they can't charge to a particular client or on a particular job, so therefore is a loss to the company...

    Exactly right, but here is the main problem situation that follows logically from this and yet management didn't anticipate:

    They _think_ they can't charge it because customers don't want to pay more. But management sells the idea to customers that something that was never billed and thus never built in the past somehow made it into the product: "Sure we can do that, it's really easy to change!", "No problem we have just finished something similar for a client, we can reuse that for you!", "You want 'modules', no problem, of course we have a modular system!"

    And then a year later they are seriously questioning how come all projects lately are going over-time and over-budget.

    And the real kicker: they are still billing by the hour, so this time we NEED to finish and we are NEVER going to recoup the costs, and it STILL isn't modular. And this repeats and each cycle it becomes worse...



  • @RTapeLoadingError said:

    Where I work we are really pushing to improve this side of the business - we've spent a fair amount of time talking but we're actually doing something about it now.

    If I may ask, what was the talking mainly about and did management realize it first or did the development team bring it to their attention? And last but not least, is doing something refactoring, or starting from scratch?



  • @random0xff said:

    @RTapeLoadingError said:

    Where I work we are really pushing to improve this side of the business - we've spent a fair amount of time talking but we're actually doing something about it now.

    If I may ask, what was the talking mainly about and did management realize it first or did the development team bring it to their attention? And last but not least, is doing something refactoring, or starting from scratch?

     

    My area is not really development focused so we were talking about better knowledge sharing, re-usable project documentation, centralised resources, etc.  The talk has been at all levels but has never really solidified into anything concrete until now.

    We want to get away from everyone having their own silo of information which results in other people having to reinvent the wheel. 

    The 'doing' will be a combination of creating new documents from scratch and taking the best project documentation and making into templates.



  • wikis can be awesome, but you gotta keep em up to date. bake some doc time into your estimates maybe?



  • @Zemm said:

    Some things (like simple Flash games/simulations) take us 1-2 days that the boss reckons we should be able to pump out in 15 minutes!

    You don't have the "create flash game" button in your version?  Perhaps you need to update to the "pro" version?

    Real magic isn't turning a prince into a frog but specifying what kind of frog with just a flick of the wand.



  •  We're going to take time out to set up the info repositories.

     Maybe ongoing maintenance needs to be baked into estimates.


Log in to reply