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 been programming for a couple of years and have often found myself at a dilemma.

There are two solutions -

  • one is simple one i.e. simple approach, easier to understand and maintain. It involves some redundancy, some extra work (extra IO, extra processing) and therefore is not the most optimal solution.
  • but other uses a complex approach,difficult to implement, often involving interaction between lot of modules and is a performance efficient solution.

Which solution should I strive for when I do not have hard performance SLA to meet and even the simple solution can meet the performance SLA? I have felt disdain among my fellow developers for simple solution.

Is it good practice to come up with most optimal complex solution if your performance SLA can be met by a simple solution?

share|improve this question
10  
see: How do I avoid “Developer's Bad Optimization Intuition”? "Unfortunately, developers generally have horrible intuition about where the performance problems in an application will actually be...." –  gnat Sep 14 '12 at 14:25
1  
Will "not the most optimal" still be "good enough"? Then stay with that. –  user1249 Sep 14 '12 at 15:57
8  
Yep. "Le mieux est l'ennemi du bien." Voltaire. ("Perfect is the enemy of good.") Good enough is good enough -- until performance testing says otherwise. –  David Hammen Sep 14 '12 at 16:20
    
I find that (in general) simple implies efficient. So there often isn't a need to compromise. –  Dan Sep 14 '12 at 19:52
2  
“It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.” – Antoine de Saint-Exupery –  keuleJ Sep 14 '12 at 19:56

9 Answers 9

up vote 56 down vote accepted

Which solution should I strive for when I do not have hard performance SLA to meet and even the simple solution can meet the performance SLA?

The simple one. It meets spec, it's easier to understand, it's easier to maintain, and it's probably a whole lot less buggy.

What you are doing in advocating the performance efficient solution is introducing speculative generality and premature optimization into your code. Don't do it! Performance goes against the grain of just about every other software engineering 'ility' there is (reliability, maintainability, readability, testability, understandability, ...). Chase performance when testing indicates that there truly is a need to chase after performance.

Do not chase performance when performance doesn't matter. Even if it does matter, you should only chase performance in those areas where the testing indicates that a performance bottleneck exists. Do not let performance problems be an excuse to replace simple_but_slow_method_to_do_X() with a faster version if that simple version doesn't show up as a bottleneck.

Enhanced performance is almost inevitably encumbered with a host of code smell problems. You've mentioned several in the question: A complex approach, difficult to implement, higher coupling. Are those really worth dragging in?

share|improve this answer
    
your answer is very helpful –  ManojGumber Sep 14 '12 at 15:11
1  
As simple as possible, but not simpler; As fast as possible, but not faster; etc –  user606723 Sep 14 '12 at 17:20
1  
"When in doubt, use brute force" ;) –  tdammers Sep 14 '12 at 23:51

Is it good practice to come up with most optimal complex solution if your performance SLA can be met by a simple solution?

Optimal is an ambiguous word!

Ultimately, if there is much risk in having to maintain the complex one, and if the simple one is "good enough" I'd always err on the side of the simple one.

Add in any risk of the complex one not being good enough, then KISS is probably the right answer.

share|improve this answer

Simplicity is prerequisite of reliability. If you have a simple solution that works, by all means go for it! It is much easier to optimize a working program than to make an optimized program work. Also do not forget about Moore's law: if your simple solution meet the performance goals today, it will probably crush them1 in a year or two.


1 There's no guarantee there, because as Jimmy Hoffa noted in his comment below, Moore's law has its limits.

share|improve this answer
    
You forgot about Moore's other law which states, "Oops, about my first law.." Sorry boss, Moore's law is no more (pun pun). I don't disagree with the rest of your point, I would just at the least caveat that last part there. –  Jimmy Hoffa Sep 14 '12 at 14:13
    
@JimmyHoffa Done. Thanks for the note! –  dasblinkenlight Sep 14 '12 at 14:20
2  
Sorry, but in all my experience in this industry. "work sets" are increasing FAR faster than the speed of our hardware, which is consistently upgraded. Really, I would just remove the Moore's law point. –  user606723 Sep 14 '12 at 17:19
    
@user606723 The growth of "work set" point is orthogonal to "optimized or simple" question: the workload will catch up with them regardless of which solution they implement. The point of bringing in Moore's law into the mix was to point out that even if the simple solution is under some performance pressure at the time of writing, the pressure will decrease as faster hardware becomes available. –  dasblinkenlight Sep 14 '12 at 17:31
    
@dasblinkenlight, the growth of the workset is no more orthogonal to the question than moore's law is. The point of bring the workset into the problem is that if a simple solution is under some performance pressure at the time of release, the performance will be insufficient in the very near future as the increasing workset demolishes any performance improvement achieved by improved hardware. While I am all for simple, reliable and maintainable software, releasing software that is already under performance pressure at release and expecting moore's law to even it out is a terrible philosophy. –  user606723 Sep 14 '12 at 19:33

When evaluating two approaches, one being simpler but less efficient while other being more complex and more efficient, one has to consider the problem and the project domain.

Consider a multi-billion software project for healthcare industry which has planned lifetime for over 15 years of maintenance and +20 years of use. In such a project performance is definitely not going to be a concern, but project complexity and structure can cause major problems for the maintenance of the project, which lasts for that 15 years at minimum. Maintainability and simplicity come before anything.

Then, consider another example. A console game engine which is supposed to power the upcoming games of the company for the next 5+ years. Because games are extremely resource-constrained programs, efficiency goes before maintainability in many cases. Writing your very own, very specific data-structures and algorithms for some task can be very important even if it goes against any kind of "best practices" of software development. A good example of this could be Data Oriented Design in which you store your data in similar data arrays, rather than in actual objects. This is to increase reference of locality and as such increase CPU cache efficiency. Not practical, but very crucial in the given domain.

share|improve this answer

Take a lesson from Knuth here: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil".

Think about your solutions in this order: First, always, correctness. Second, improve clarity and simplicity. Third, and only when you can demonstrate the need, efficiency.

Adding efficiency will almost always cost you something important, and so should only be pursued when you know you need to.

share|improve this answer
    
thanks for quote from master Knuth..very helpful –  ManojGumber Sep 14 '12 at 15:15
3  
Note that this does not mean you should not write a good implementation in the first place. –  user1249 Sep 14 '12 at 16:43
    
@ThorbjørnRavnAndersen : of course, that is what the first two points are about. –  simon Sep 14 '12 at 17:09
    
@simon the quote is frequently used as an excuse to choose sloppily, –  user1249 Sep 14 '12 at 17:37
    
About your second point: I had a colleague who quite often stated that he preferred incorrect well structured and clean code before correct spaghetti. –  Buhb Sep 14 '12 at 21:21

This is always a hard question and I see answers swinging one way, so I'll play the game for the other side, though I don't claim either answer is correct, it's a very soft and case-by-case topic.

One thing about a complex but high performance solution is you can always just document the ever living heck out of it. I'm generally a fan of self-documenting code, but I'm also a fan of software that responds in an amount of time that makes me feel like it's not slowing me down. If you do go with the complex but high performance solution, consider what you can do to make it not so bad:

Wrap it in an interface, put it in an assembly on it's own, possibly even a process all it's own. Make it as loosely coupled as possible with as thick an abstraction wall around it as possible to avoid leaks. Write lots of unit tests for it to save regressions in the future.

Document it in the code, even consider writing some real documentation. Think about complex data structures and how they're documented, imagine trying to understand the implementation of one of them from code without a data structures book/wikipedia article to explain it. And yet we all accept that these complex data structures are in fact good things and it's beneficial that someone did implement them in our languages.

Remember that we're all sending messages on a TCP/IP stack that is likely as harry as code can get if any of us were to look at it, expressly so it performs the way we all require it too. Perhaps your problem doesn't require this level of optimization, perhaps it does, but beware when tackling this question as we all have to from time to time: There be dragons there.

share|improve this answer

I'd prefer the simple one. In my opinion the premature optimizations cause as much problems as they solve. In many cases good design allows you to change given implementations in the future, if they become bottlenecks.

So at the bottom line - I'll design it as flexible as possible, but won't sacrifice simplicity for flexibility too much.

share|improve this answer

Short Answer: Prefer the simple solutions over complex, and remember KISS and YAGNI principles

Because initial project requirements and software is never perfect, it requires changes as application is developed/used. Iterative approach in development phases is a very good match to start things simple and extend it as needed. The simplest solutions have room for flexibility and more easy to maintain.

In addition, trying to be smart and placing some add-hoc optimization while still building your application is not a good practice and may over-complicate your solution. As it is known, "premature optimization is the root of all evil" - from Knuth's book

share|improve this answer
1  
@EIYusubov thanks for the KISS and YAGNI reference –  ManojGumber Sep 14 '12 at 15:20
1  
@ManojGumber, no problem and its really the essence what we as programmers should care in first place. –  Yusubov Sep 14 '12 at 15:26

Which one costs less?

Most of the time, a simple solution that's slightly slower will be perfectly acceptable in terms of performance, and simplicity makes it cheaper to develop, maintain, and eventually replace.

On the other hand, sometimes speed is really important, and the financial gain that comes from even small speed improvements can be far greater than the increased cost of a more complicated solution. For example, shaving 0.01s off the time to complete a transaction can make a securities trading system much more profitable. A 10% improvement in efficiency of a system that supports several million users could mean a significant reduction in server costs.

So, the question you have to ask yourself is: Does using the complex solution have enough of an impact on the bottom line to pay for its additional cost? Actually, you should probably ask your client to decide since they're paying the bills and reaping the potential benefits. One good option is to go with the simple solution first, and offer the more complex solution as a possible improvement. That lets you get your system up and running and gives your client something to start testing, and that experience may inform the decision to implement (or not implement) the more complicated solution.

share|improve this answer

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.