2

I've recently gotten a contract for me to integrate an API with an AngularJS frontend, I'm quite new to freelancing and I've only got roughly two projects under my belt, all be it larger than normal, one taking six months and the other is at around 5 currently.

However this new gig that i've got, i've just been sent the code, I just got sent a zip file with the code in it and I'm not trying to be arrogant or anything but the code is, in my eyes bad. I feel like I would have to do a lot of extra ground to get anywhere with implementing the API, does anyone have any advice on how I should proceed? Should I try and coax a redesign or should I just hand him back the code and leave it at that? Any advice would be appreciated

Grant
  • 239
  • 1
  • 5

2 Answers2

2

You took a programming job without reviewing the code? Your mistake I may say.

Anyway, clients prefer that you are honest with them. Tell them that you reviewed the code and it's bad because of A to N points.

You can offer to do it all from scratch or to continue working on it but new features will probably include other fixes and refactoring. So the client should now that implementing feature A takes 5 hours, but in this case it may take 8 or 10 or X hours.

In your elaboration, try to explain all bad sides of continuing working on such code. This is important because at some point the bad code will start taking its toll, and you should not be blamed for that.

It's unclear how the client will continue. Depends on this budget and time frame.

In my past, clients sometimes chose to start from scratch, but at least 70% or 80% time, they will tell you to continue coding and patch it in the progress. Most of those apps now work well, thou unpredicted bugs happen all the time. Neither of my client blamed me for them or refused to pay me for fixed. Honesty is the key, aside to expertise and professionalism.

Peter MV
  • 14,379
  • 1
  • 34
  • 67
  • Thanks for the info, I'll make sure I review code in future – Grant Jul 03 '15 at 15:22
  • It's not necessary, but it's recommended so the client can plan his budget accordingly. We can work on good or bad code. It's just work on the bad code will take more time and bugs can be harder to predict. – Peter MV Jul 03 '15 at 15:24
  • Many clients won't send you the code until after they've hired you. It's a complicated situation for everyone. – user45623 Jul 10 '15 at 18:33
  • Yes, but for such clients you tell them that you cannot deliver fix price. Or to be more price, I NEVER give fix price for fixing the code. It's impossible to predict all the issues you can meet. – Peter MV Jul 11 '15 at 07:29
1

I think there will always be scope for improving things. The best you could do was to tell them your view and tell them consequences of bad coding done so far.

So far client may have invested quite some time and money and may have gone in to process subtlities which may not be that apparent - so you may need more time before you suggest more.

Also management always leads technology - you may just want to deliver what Client have asked and resist temptation of improving code.

purely my 2 cents

alpa
  • 101
  • 3
  • 1
    Yeah, I'll say I'm surprised this wasn't chosen as the better answer. Your client will distrust you if you start complaining about the code base at this point. The time for that expires after you make a quote. It's too late to talk about the problem now without making the client feel like they were just baited and switched.

    The only honest way out (that I see), if you do want to back out, is to tell the client that you didn't expect the code to be so complex and that you won't be able to continue the job in the given time frame with the given budget.

     – jbangerter Jul 11 '15 at 17:50