Quantity over Quality?

[YaderBH]

Hi,

How many of take the time to put quality into code?

Where I currently work I've noticed that half done / working code gets pushed to production and its accepted.

What are you minimum requirements to say it's enough ? Dead lines are the killer, as always.

If time is an issue at a minimum I write unit tests, implement design patterns, and follow certain principles such as "a method should do one thing really good" or "the Samurai Principle", etc.

I would like to hear everyone's thought on this. I know everyone preaches best practices, but how much of that is actually applied?

[ethanp]

With PHP in particular, it is extremely important (I feel) to pay attention to code styles, readability, and organisation. It is far too easy in PHP to write crappy code. A team code style guide, a unit-testing requirement, and mandatory code review (the "fresh eyes" approach) will certainly help to ensure that this happens.

Do people do this? Probably not, mainly because most development workplaces are focused on deadlines and results. Non-developers are usually in charge and do not necessarily understand the value of good code.

[sunwukung]

The question is not how many of us take time to write "quality" code - rather how many of us work for companies that provide time for us to write quality code. It's also worth pointing out that asking the author of the code to judge the quality of his own work is a somewhat flawed surveying method

[TomB]

Off Topic:

I feel this is applicable: http://xkcd.com/844/

[Zurev]

Off Topic:

I feel this is applicable: http://xkcd.com/844/

heh, nice one TomB.

Yeah, unfortunately I'm in the same situation as the OP. I've gotten put in situations where I have to work on existing code and it is just obscene. Have to backtrack for hours to implement a simple fix, and then for some reason that isn't working, and it's a huge ordeal.

I try to do best practices always, and haven't had many issues as of yet, however deadlines are deadlines, and that's what it comes down to unfortunately.

I'm also extremely against the lack of project planning that exists before a project is initiated, however that may just be me in that boat. :-p

[oeyvind]

I think complexity/obesity is a key point when it comes to quality. Because when your code/architecture becomes complex, you often come into a situation where your application is:

• Slow
• Resource intesive
• Harder to debug
• Error prone because more things can go wrong

Which leads you to add caching and spread it over more servers, making it even more complex.

I think Einstein said, "Keep it as simple as possible, but not simpler".

For example, when you implement something like Zend MVC, you add to your project:

• htaccess files, which require mod rewrite to be installed and doesn't work on IIS, Nginx etc
• A lot of Zend code to go through on each request before you reach the code that actually does something application-specific
• New stuff to learn, more code to debug
• etc

So I don't mean you should not use Zend MVC, just consider what your're adding to the project in terms of more code and complexity and weigh it up against the benefits.

[TomB]

I partly agree but you pointed out the flaws but not the benefits.

Generally, complex code when done properly:

-Encourages reusability
-Enables unit testing for faster development
-Provides far easier maintainability down the road due to separation of concerns. You should never have to worry about changing code in one place having unforeseen knock-on effects.

[Ren]

I think complexity/obesity is a key point when it comes to quality. Because when your code/architecture becomes complex, you often come into a situation where your application is:

• Slow
• Resource intesive
• Harder to debug
• Error prone because more things can go wrong

Which leads you to add caching and spread it over more servers, making it even more complex.

I think Einstein said, "Keep it as simple as possible, but not simpler".

For example, when you implement something like Zend MVC, you add to your project:

• htaccess files, which require mod rewrite to be installed and doesn't work on IIS, Nginx etc
• A lot of Zend code to go through on each request before you reach the code that actually does something application-specific
• New stuff to learn, more code to debug
• etc

So I don't mean you should not use Zend MVC, just consider what your're adding to the project in terms of more code and complexity and weigh it up against the benefits.

I think Zend MVC went ahead and tried to implement everything without seeing first if it was really needed.
One bug bear, is the amount of setters & getters that seems automatically created as soon as a property is added to class.
Even the proposed mini MVC interfaces have setters and getters defined in the interfaces.

http://framework.zend.com/wiki/displ...MVC+Interfaces

[pgb101]

I partly agree but you pointed out the flaws but not the benefits.

Generally, complex code when done properly:

-Encourages reusability
-Enables unit testing for faster development
-Provides far easier maintainability down the road due to separation of concerns. You should never have to worry about changing code in one place having unforeseen knock-on effects.

Just to be slightly disruptive and pedantic I would say this depends on point of view. If the view point is you start simple I would agree but I think the software software learning curve starts complex and goes towards simple(elegance) with experience. The battle is keeping things simple enough a human brain has a hope of keeping it organised while more and more is added to unimaginable scale( unimaginable is the keyword and this is a lifelong quest of never achieving the finish ). The human brain has a disposition of going for the most biased answer versus the simplest answer, if you want to compare Einstein to the luddites interpretation of Occams Razor("the simplest explanation is more likely the correct one"), the beauty of Einsteins is the need for appreciation of the "not simpler" part and that is where the wisdom of what he said lies. The previous part is ignorable in comparison as it is almost a playful misdirection of words. Fist part is easy, the second part is the quest.

The original question "Quantity over Quality?".
Define quantity. 100 features, 1000 features, 100000 features. Did those features fit the framework etc? How many broke the habitat? How many features did that implementation leave undoable( If you think there is no point of undoable in the future that is just a lack of twisted imagination and naivety ). Unless this is defined then everyones answer will have a different basis. Quality will always beat quantity at some point, but is is a bit like a tree falling down in the woods. Will anyone be around and working on it at that point or is that point never experienced so never exists? On a side notr how much do you feel you have outgrown your job and do you have a timeline for leaving? What are your opportunities for moving on?

After we define quantity we can fight about quality

[oeyvind]

As for quantity vs quality: at work the management wants to add all sorts of features and bring in lots of other companies and provide solutions to them, which I don't agree with, because we are already in deep water and do not have a high quality on existing systems and services. We don't have a solid foundation, it's kind of falling apart but getting the problem fixed at its root is never a priority, and so we end up with different kind of hacks, which makes the whole architecture more complex to maintain and work with.

I think you will sell more and have more happy customers if your product and general service is of high quality. You'll get a reputation of being good quality, which will make people trust you and maybe even recommend you to their friends (which is the best kind of advertising, and free).