This breaks down into two problems as I understand it.

• You don't like the structure of the code
• You know how to improve the code(struture) to make future changes, and have the technical acumen to do so, but it is not part of the specification under which you are hired(contract)

What should one do? In my opinion...

• Complete the contract per specification and per contract(obviously)
• Approach the the lead tech and whoever has their hands on the money (perhaps one before the other, (you would have to chose which is more likely to solve your problem) and explain the advantages of the refactoring. Things like
  • an estimate of how many hours it would take(cost)
  • how many hours it would save subsequently assuming more functional changes are desired
  • other pros
  • other cons

When it boils down to it, from a contractual standpoint, making the code better outside the currently contracted specification is not your problem. Your problem is that you are diligent and wish to save the customer future expense. A laudable trait. So the best you can do in my opinion is to offer up the additional service and let the customer choose whether they want to take on that expense. And then live with their decision and 'let it go' if they choose not to take you up on it. Should they hire you in the future, you can always say no if it bothers you much.

But I am thinking that you will increase your chances of being contracted again if you make the effort, even if you are turned down. As long as you stay positive, and do not criticize the existing code base. There is a lot of difference between criticism and 'presenting opportunities" though communicating that way is pretty nuanced.

This is not so much what you "should" do as it is what you "can" do which positive for you in that you have addressed what bothers you in a positive, diligent and professional way. You end up respecting yourself for having addressed that which might benefit the customer, and respecting them either way that they decide(though that might be quantitatively and/or qualitatively less if they reject your proposal, regardless - you have shown them respect).

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.