http://www.perlmonks.org?node_id=286578


in reply to Sub-initiate needs help getting started

I'm going to join the chorus of "good luck" and also "the consultant should be shot".

I'm also going to say you're in a very sticky situation.

How's this for a question -- why are you attacking this problem from behind?

You've got 8,000 lines of bad code -- forget that for a second, what is it that you want to achieve?

If you've got a database and you've got some expected output, we might well be able to bridge that gap with a new script. Is the JavaScript necessary, or does your boss just need to see reports on x number of widgets sold on the east coast versus x number of widgets sold on the west coast?

Considering what we know about your consultant, they might very well not be very good reports in the first place.

So I'm saying, what if you go back to your boss and say "forget the exact details, layout etc of the reports you have now, reproducing them is a very complex job -- what do you really need to know? I'll start on that." and take it from there.

Getting data out of a database into a web page is not the hardest task you will ever face in Perl.



($_='kkvvttuubbooppuuiiffssqqffssmmiibbddllffss') =~y~b-v~a-z~s; print

Replies are listed 'Best First'.
Re: Re: Sub-initiate needs help getting started
by blackstarr (Friar) on Aug 26, 2003 at 07:20 UTC
    As someone who develops reporting structures for a living, I'll second that, forget what your inept predeccessor has done and redo it from scratch. Approach it as if it were a brand new request.

    Forget the look & feel until you are answering the correct questions ... then the look and feel will be easy.
    If you handle the data output (answers) as totally seperate from your presentation (format), then you will find that if either requirement changes, it will be a simple matter to update the code.

    Good Luck & ...
    So Long
    blackstarr

      I'd agree with you if it weren't for the fact that the "from scratch" part of this problem includes the fact that the (hi! welcome to the club!) new developer (here's your new hat!) is woefully unprepared to know what the issues/problems are and where to find solutions that fit them. Of course, I have that problem too and I've been doing this for years.

      In any case, I don't think it's an answerable question short of seeing the code itself and ideally the functional specs for what the code is apparently solving. Figuring out legacy code can do wonders for jumpstarting your knowledge base (it's how I got started) and limits the feeling of helplessness that can hammer you if you have no experience in handling this sort of situation.

      This may not fit the goals of the original poster, but you might consider hiring another consultant. And checking if they have a handle here for good measure ;). Hell, even if the company won't go for it, it might be worth paying some amount of your own personal money to get a little hand-holding as you work through it. Or just abuse the hell out of SoPW for the cheap, yet amazingly effective method!