Good fix vs Quick fix [duplicate]
- by Andrea Girardi
This question already has an answer here:
Does craftsmanship pay off? [duplicate]
16 answers
Good design: How much hackyness is acceptable? [duplicate]
9 answers
How do you balance between “do it right” and “do it ASAP” in your daily work?
14 answers
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.
