Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
3  
'quality' to me is a not a specific term. It could mean one or more of the following: Correctness, Performance, etc. The answer may vary depending on the attribute. For example, correctness should not be sacrificed for time. –  Emmad Kareem Aug 25 '11 at 23:21
    
I agree. I should have been more specific. I assumed correctness to be there already. –  AdamJMTech Aug 25 '11 at 23:26
    
Lookup technical debt and you will see lots of thoughts on this. –  Kyle Heironimus Aug 26 '11 at 2:35
1  
This question assume that devellopeing quality code is slower than develloping good code. This, in general, false, at least for any piece of code that require more than 1 day of work. Unless you are used to produce code that is just crap and need to learn some good practices. –  deadalnix Aug 26 '11 at 11:51
add comment

8 Answers

up vote 11 down vote accepted

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.

share|improve this answer
    
Another problem with over-engineering is that the overall level of the team is always getting higher and higher, and it's much more difficult to recruit. So the cost is not only in the time the developer spend wasting the money, it's the lack of available profiles that cause trouble to the business. –  user2567 Aug 26 '11 at 11:17
add comment

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

share|improve this answer
add comment

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.
share|improve this answer
add comment

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 :-)

share|improve this answer
add comment

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.

share|improve this answer
add comment

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! :-)

share|improve this answer
5  
There will be no maintainer to care about how good/bad your code is, if you miss the deadline and the project is killed or the company goes bankrupt. –  hotpaw2 Aug 26 '11 at 1:26
    
I think this answer is almost completely wrong except in the best of ivory tower jobs. I hate when people show me messy code too, but I like it a lot when people tell me that messy code was written so that the company could make many thousands (or millions!) of extra dollars because it helped launch the product a year earlier. Besides, as a programmer, it's nice to be able to go refactor and rewrite initial code. People love to say "iterate and release quickly", but they forget the implication that Iteration #1 is probably going to be low quality. Hope your company makes money someday, perl. –  Jordan Aug 26 '11 at 5:24
    
As a follow-up, I believe good habits and familiarity with the right ways of doing things are good things that lead to high quality code. I also believe that high quality means a lot of things to different programmers, and that most get hung up on trivialities like style and NIH syndrome. That's to be avoided like the plague. –  Jordan Aug 26 '11 at 5:26
    
@Jordan: I disagree with your comment: shipping quicker is not always the best solution. As a programmer, it is part of your job, I think, to also know when to build quality and when to ship (which do not always falls on the same side, depending on multiples factors). The example of making tons of money for shipping faster is just a cute thing to tell yourself after working a lot of overtime but I'm not convinced it is necessary true, especially when quality is compromised (I am the type of customer who cares about quality .. but yeah I know this is rare these days). –  n1ckp Aug 26 '11 at 15:07
    
I'm not saying that you shouldn't deliver quality, but there is a huge difference between what many programmers consider quality, and what customers consider quality. Programmers tend to obsess over minutiae that don't generally affect the long-term life of the software. The problem with not releasing to the customer is that you've launched without really knowing what the customer wants. Despite rounds of UAT and specs, it's the real world delivery that determines the customers expectations of quality, and of course brings in money. –  Jordan Aug 27 '11 at 14:21
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
"over engineering" is, by definition, wasteful. –  Caleb Aug 26 '11 at 1:32
    
Technically yes. I am suggesting that a little over engineering is not wasteful for the company itself. Looking at attrition rate in IT companies and hiring costs and risks. –  arunmur Aug 26 '11 at 6:53
    
It sounds like you equate "over engineered" with "heavy duty," "robust," and "built to last." There's nothing wrong with building software with those values in mind, but if that's what's desired it should be in the requirements in the first place. In software, "over engineered" usually means "more complicated than it needs to be," and that's not a good thing. –  Caleb Aug 26 '11 at 10:56
    
Yes. To me over engineered means developer spends more time with the code after it is essentially complete to improve tiny minute things. Some times even re-factor the code(and re-write test cases) after fixes. Complicating architectures in general are not good especially when the developer is flying blind. –  arunmur Aug 26 '11 at 12:11
1  
Just be aware that to many in the field, "over engineered" means bringing a Howitzer to a knife fight. It's using BigTable when an array would do nicely. Any code should always be able to reliably meet requirements, but if exceeding requirements takes any additional work, that work is, by definition, not required, and therefore wasted in the context of the requirements. If that additional capability turns out be necessary, then the requirements were wrong. As a developer, however, you generally shouldn't be second guessing the requirements. –  Caleb Aug 26 '11 at 12:41
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.