Fake ASP WTF



  • After years of mocking people's WTF jobs on this site, I finally got my comeuppance.

    Today at work our graphic designer asked me to help her make a "little change" to our company's web site.  She's the maintainer of the site, but as a graphic designer by trade, she doesn't really get into the code side of things.  It turns out she wanted to rearrange an item in the menus -- move a subheading to the top menu.  She wasn't sure how to do it, so thats where I come in.

    I went to the site and hit 'View Source' and it looked like standard ASP stuff, lots of controls with dynamic gibberish for names.  Definitely a master page with some dynamic menu controls and content sections.  Should be no problem, so I ask her what the directory is so I can pull up the master page and show her what to change -- and that's where things got ugly.

     There was no master page in this directory, just a ton of aspx files.  That's odd.  I opened one and found out that it was actually a completely static webpage.  It ended in aspx, but you could've renamed it to html and been just fine.  The strange thing is that it was full of ASP-ish looking HTML.  Almost like someone had just hit "view source" from an ASP site and saved the output as an aspx file.

     Oh, no.  Tell me we didn't....

     Yep.

     Every other ASP page -- 100+ -- was a different static copy of a page on one had once been a dynamic ASP site.  This meant that common content that was once in the masterpage was now replicated 100 times... and completely unmaintainable.

     It turns out that someone in management had a problem -- "When the graphic designer needs to make changes to the web site, she ends up burning developer hours.  How could we solve this?"

     And the solution to every problem is of course, an intern.  This intern had been tasked with the job of browsing our entire site, saving the source of each page as its own aspx page, and then fixing up the links.  I have no idea how long this took our intern, but it's a miracle he didn't kill himself.  And now that we had a giant, static site, our designer could make changes to her hearts content using her WYSIWYG editor of choice.  Brillant!

     Unfortunately, this meant touching up to 100 files, depending on what she wanted to change.  But at least there are no developer hours be wasted in this process!  Apparently graphic designer hours do not have actual value.

     
    The real test of the WTF-ness will be the response I get from management.  I sent an email with an overview of the problem and the solution (switch back to a real ASP site and give our designer some training on how to update it, at the expense of some of those precious developer hours) and the repercussions if we don't (our designer quits her job in disgust or our site never gets updated).  I'm not terribly confident that they'll let me spend the time needed to fix the problem.
     




     


  • Winner of the 2016 Presidential Election

    Ugh.  I've had to put up with similar things, though on a much smaller scale.  I had another developer take the nasty rendered output of one ASPX page and create another ASPX page with it, leaving the ID and metadata mess.  I don't care though, because that's his mess to maintain.

    I have however, recently had to take several hundred static HTML pages and make broad changes to all of them; only to find that they had diverged enough that a global search-and-replace would usually only exactly match 20% of them at a time.  Joy.  I severely under-bid the hours necessary for those changes, for much the same reason: I expected to be able to perform each change only once.  (We bill based on estimates; if it takes longer than expected, we eat the cost.  Ouch.)  Most of them were invalid markup and atrocious table-based tag soup; but I wasn't being paid to, nor was I asked to, fix that; so I left it.



  • @zip said:

    ...browsing our entire site, saving the source of each page as its own aspx page, and then fixing up the links.  I have no idea how long this took our intern, but it's a miracle he didn't kill himself.
    I use Dreamweaver, which despite its bugs is fairly useful for web dev. You can open any amount of pages, and do a find/replace with all open documents, and even use regexes. And I'm sure there are plenty of other programs that will do this rather quickly.

    It would be a pain if the formatting of some/all pages are different, though. I, too, have felt the pain of having to do repetitive tasks because of WYSIWYG editors >=/
     



  • @boolean said:

    @zip said:

    ...browsing our entire site, saving the source of each page as its own aspx page, and then fixing up the links.  I have no idea how long this took our intern, but it's a miracle he didn't kill himself.
    I use Dreamweaver, which despite its bugs is fairly useful for web dev. You can open any amount of pages, and do a find/replace with all open documents, and even use regexes. And I'm sure there are plenty of other programs that will do this rather quickly.

    It would be a pain if the formatting of some/all pages are different, though. I, too, have felt the pain of having to do repetitive tasks because of WYSIWYG editors >=/

    Congratulations, you are using a large complex commercial application to do what any unix user does every day, in their sleep, with the basic system tools.
     



  • @zip said:

    And the solution to every problem is of course, an intern.

    Which leads us to the great Zen puzzle of WTFs: is it more stupid that the intern's time was wasted manually simulating wget -r, or that somebody thought this was even remotely close to a sane thing to do in the first place? 



  • Hey, I can't wait until the company do a re-branding and figure out how much of a pain in the a changing the logo, colours, font etc on each page is going to be!!



  • @asuffield said:

    @zip said:

    And the solution to every problem is of course, an intern.

    Which leads us to the great Zen puzzle of WTFs: is it more stupid that the intern's time was wasted manually simulating wget -r, or that somebody thought this was even remotely close to a sane thing to do in the first place? 

    The intern can plead ignorance.



  • @asuffield said:

    @zip said:

    And the solution to every problem is of course, an intern.

    Which leads us to the great Zen puzzle of WTFs: is it more stupid that the intern's time was wasted manually simulating wget -r, or that somebody thought this was even remotely close to a sane thing to do in the first place? 

     
    It could be argued that no one told the intern NOT to use wget -r.  For all I know he did it that way and then spent a week surfing the web.  Or, he was too dim to think that there might be a better way, which would also explain why he had the free time to take on this task. 



  • @zip said:

    It could be argued that no one told the intern NOT to use wget -r.  For all I know he did it that way and then spent a week surfing the web.  Or, he was too dim to think that there might be a better way, which would also explain why he had the free time to take on this task. 

     

    I would have used wget -r and then spent the week surfing monster.com looking for another job.   



  • It probably still looked better than the crap that GoLive! produces...



  • This is front-page-worthy, IMO.  Ugh. 

    @joe.edwards@imaginuity.com said:

    I severely under-bid the hours necessary for those changes, for much the same reason: I expected to be able to perform each change only once.  (We bill based on estimates; if it takes longer than expected, we eat the cost.  Ouch.) 

    I think the way we do it here, is you've got two options: First, we estimate how many hours the job'll take, and we let you know how long that is.  Then we offer to either tackle the job at an hourly rate, with the client paying for any potential overages, or we'll do it for a flat rate, based on the hourly rate X hours estimated X 1.5

     



  • @merreborn said:

    This is front-page-worthy, IMO.  Ugh. 

    @joe.edwards@imaginuity.com said:

    I severely under-bid the hours necessary for those changes, for much the same reason: I expected to be able to perform each change only once.  (We bill based on estimates; if it takes longer than expected, we eat the cost.  Ouch.) 

    I think the way we do it here, is you've got two options: First, we estimate how many hours the job'll take, and we let you know how long that is.  Then we offer to either tackle the job at an hourly rate, with the client paying for any potential overages, or we'll do it for a flat rate, based on the hourly rate X hours estimated X 1.5

     TRWTF is he gave an estimate without looking at the system.
     



  • @Random832 said:

    @merreborn said:

    This is front-page-worthy, IMO.  Ugh. 

    @joe.edwards@imaginuity.com said:

    I severely under-bid the hours necessary for those changes, for much the same reason: I expected to be able to perform each change only once.  (We bill based on estimates; if it takes longer than expected, we eat the cost.  Ouch.) 

    I think the way we do it here, is you've got two options: First, we estimate how many hours the job'll take, and we let you know how long that is.  Then we offer to either tackle the job at an hourly rate, with the client paying for any potential overages, or we'll do it for a flat rate, based on the hourly rate X hours estimated X 1.5

     TRWTF is he gave an estimate without looking at the system.
     

    Isn't that standard practice?  In my industry, the contract is signed and a go-live date given before the devs even see the list of modifications.
     



  • @Quinnum said:

    @Random832 said:
    @merreborn said:

    This is front-page-worthy, IMO.  Ugh. 

    @joe.edwards@imaginuity.com said:

    I severely under-bid the hours necessary for those changes, for much the same reason: I expected to be able to perform each change only once.  (We bill based on estimates; if it takes longer than expected, we eat the cost.  Ouch.) 

    I think the way we do it here, is you've got two options: First, we estimate how many hours the job'll take, and we let you know how long that is.  Then we offer to either tackle the job at an hourly rate, with the client paying for any potential overages, or we'll do it for a flat rate, based on the hourly rate X hours estimated X 1.5

     TRWTF is he gave an estimate without looking at the system.
     

    Isn't that standard practice?  In my industry, the contract is signed and a go-live date given before the devs even see the list of modifications.

    There are a number of industries that work this way (for example, the construction industry uses a variation on it). Without exception, they are all industries in which budget and schedule overruns are the norm. Strangely enough, the people involved don't appear to understand why this is the case.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.