Good fix vs Quick fix [duplicate]

Question

Let's start from this principle: quality is a feature that you can't add to a project in the middle of the development process.

This is the scenario: two weeks to go live with my project and, one of the developers added a specific method used only for one web application to our framework (Our framework is a bounce of java classes used to extract content from MongoDB, Alfresco, mySql and it's used by web applications). I'm the team leader and I told him to generalize the method to keep the framework to keep reusable but he said "no, I prefer don't do that because there are a lot of bugs that need to be fixed". The manager is agree with him and of course I'm not.

Is it better to made extra effort to keep a framework free from any specific implementation (probably used only by one web application) or just add the methods because it works?

So, my question is: is it correct to write code that only works or is better to write code that works but it doesn't sucks (i.e. adding embedded value, specific methods, extra classes, add column to database, etc)? How is it possible to justify the extra time (to be honest, this kind of fix requires 10 minutes extra to write a good generic code) to the management? How is possible to argue it's the right way to write code to young developers and PM? in general, good fix or quick fix?

Ah, 10 minutes after I get the email from PM, he asked me why on a url of application 2 there was the name of application 1 during the login?

I like to quote Jeff Atwood: "Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. "

Excerpt From: Hyperink. "How-To-Stop-Sucking-And-Be-Awesome-Instead." iBooks.

Answer 1

The answers to a lot of those questions start "All else being equal...".

If you have two weeks to go to ship, then your manager will have a lot of tough calls between dropping buggy features, patching the bugs in a hurry, or sticking to the ideal of a clean, well-developed application framework and possibly delivering late or over budget. Ultimately what matters is that the customers are happy and pay up, so I think you have to trust his judgement. What might appear to be 10 minutes extra work to you to stick to the design might not just be 10 minutes for a junior; what might appear to you to be great reusable code might appear to be gold-plating to the client. The quote from Jeff Attwood is all well and good, but if you have more broken windows than you have time to fix then you have to prioritise the ones that the rain is pouring through...

Of course when he takes the opposite view to you, you then need to be the one that speaks up for revisiting all the quick fixes and ensuring regression testing once the immediate deadlines are passed.