Quality vs Time

Question

I have heard of developers who work with code which is a complete mess because originally the code was quickly developed and the quality was not there in the first place.

Its always good to get maintainable, reusable code but I was wondering if it was best to sacrifice some of this due to time constraints. A common problem I come up against is over engineering something and wasting a lot of time. We all know in the real world due to time constraints its going to be very difficult to get near perfect code.

I was wondering if there was a general rule for getting good quality if there is not much development time? Do you find this a common problem in development balancing code quality and time?

Answer 1

The problem with over-engineering is that, just like with optimizations, developers tend to over-engineer completely irrelevant pieces. And those are usually never going to be touched through 10 revisions of the product.

While if the business requirements change, the over-engineered solution needs an extra engineering anyway.

So you really need to find a balance to write extensible, stable and readable code. Striving to implement every thing you've ever read in the books is, IMHO, bad.

And this is where architectural planning phase comes in. Find core objects, find core relations, find what are the likely business changes in the near future, and design an extensible skeleton from what you have found.

Answer 2

It's a lie. Rushing code makes for bad code, which impedes the progress of everyone who tries to work with it and increases the chance of bugs.

We try to keep code clean, especially that which makes you money or that which costs you money. Recent work on "churn" and "heat map" show us that a fairly small amount of our code is highly volatile, a difference more severe than the 80/20 rule would predict.

Know, clean, improve your code. Don't gold-plate it. Don't over-engineer it. Use the rules of simple design: 1) passes all tests, 2) no duplication, 3) clearly expresses intent, 4) has no superfluous parts.

Please look at code virtues: http://pragprog.com/magazines/2011-08/how-virtuous-is-your-code

Answer 3

These are some guidelines that are vague, but this isn't an exact science:

1. If you say to yourself, "I hope I never have to look at that code again." Fix it to the point it is tolerable.
2. Beware of the desire to spend time on things you like to avoid those you don't. You'll over do it.
3. Find out what is important to the user. They may not mind waiting for a large form to load if they can enter data faster. Even if the overall task takes the same amount of time, it's about perception not logic.
4. Following best practices doesn't always mean they take longer. When you establish good habits, you gain fluency.
5. If you obsess to the point of getting nothing done, get help.

Answer 4

One of our engineers at work is a fairly strong adherent to the 80/20 principle. If you can gain 80% of the benefit for about 20% of the effort, then it's important to stop and think about whether you are gaining something that you really want by expending more time and effort.

That is, you shouldn't compromise on something important, but for more general items, you'll get most of the benefit without going to an extreme, chasing details.

My own experience also tells me that the way a software project goes, how much of a mess it is, and how much revision it needs after you meet the deadline to convert it into something more maintainable is a function of experience.

As you gain more experience as a developer (so long as you are working on improving), projects come together naturally with less effort.

Another way of saying it, a good solution today beats the perfect solution tomorrow (with the addendum that tomorrow never comes :-)

Answer 5

Time and quality are mostly orthogonal. Certainly, you get poor quality if you rush through an implementation, and better quality if you have plenty of time for implementation, testing, and polishing. But just spending a long time doesn't ensure good quality, and getting a task done quickly doesn't necessarily mean that it was rushed or that the solution is of poor quality.

The thing that links time and quality is complexity. Generally, the more complex a system the longer it takes to implement, the harder it is to verify, and the higher its rate of defects. Simpler solutions are easier to understand, faster and easier to implement correctly, likely to have a lower rate of defects (i.e. higher quality). The simple solution isn't always the obvious one; it often takes more time up front to create a simpler design, but that time is usually well spent and pays dividends in quality and development time later.

Answer 6

My Rule: QUALITY BEFORE QUANTITY OR TIME!

Why? Because I hate when people show me messy code that has no comments. If someone gives you 2 weeks to get the job done, take two weeks. There is no rush.

It is not hard to balance time and quality. Especially if you always use Best Practices, and you are just use to having good quality. Here is my rule for quality:

When writing a program, type like the guy who will be maintaining it will get a chainsaw on you if there is something he doesn't understand! :-)

Answer 7

It seems to me that the less time you have for coding, it is likely that there are even more worrying cuts in testing time which will almost certainly have a knock on on quality.

Additionally, if you are short on time, your best bet for getting good clean code (as far as is possible) is in a) having good clean clear and non-ambiguous requirements and a code base which is already reasonably clean so that the discipline is already in place. Unfortunately, very few ideal worlds exist.

Answer 8

To me this is kinda true. There is a threshold amount of time a task needs before its called complete. If less than allocated time was spent then it tends to be too little engineered if more was spent it would be over engineered. It is very complicated mathematics to find the exact threshold. So a manager in reality can almost never know if it was over engineered or under.

About over engineering, I believe a manager can set the expectation on what one can over engineer on. I would set very high priority to covering almost every single line of code with test cases. This means for every line of code written the developer has to spend 4-10 times as much time to just write test cases. This will eventually add to the product quality. If you have truly good developers they will over engineer despite this.

Also, I dont consider a little over engineering is a waste of time

• A developer who over engineers often is doing the task with a lot of interest taken.
• Gives a little satisfaction to the developer, so he is likely to stay longer with the company
• Over a long term developer gets to learn on aligning his over engineering with that of the business(as no one likes to write a piece of code no one wants to use).
• Sturdier over engineered code is faar better than a week code that needs a visit to the bug fix department every week.
• Over engineering often allows developers to express their newly learned concepts, so basically he will teach the whole team what he learnt through the code.
• Allowing developers to over engineer gives you real power to ask them to quickly develop a few things. They will consider this a serious request.

It eventually comes down to what your company is doing. If its a company consuming its own code then its not such a problem but if its a company who is developing for others at $/hour rates then you might want to set your priorities with the paying company.

Edit: My idea of over engineering seems to be that developer spends more time with the code than actually needed after completing it the simplest possible way he thinks it can be done.