Comments on: Thoughts on how to evaluate code http://www.sworddance.com/blog/2007/05/29/thoughts-on-how-to-evaluate-code/ Thu, 20 Nov 2008 13:37:17 +0000 http://wordpress.org/?v=2.6.3 By: patrick http://www.sworddance.com/blog/2007/05/29/thoughts-on-how-to-evaluate-code/#comment-8595 patrick Fri, 12 Oct 2007 08:46:01 +0000 http://www.sworddance.com/blog/2007/05/29/thoughts-on-how-to-evaluate-code/#comment-8595 Hi Renat, You are correct that not every website needs to be able to handle the load that amazon handles. And it is important for there to be reasonable expectations as to the needs. So when doing performance testing the simulated load needs to be inline with expected traffic. However, consider these issues: <ol> <li>The website may be highly successful, or be slashdotted/digged/etc. Being able to handle the 'success' of a favorable review is critical. Otherwise, a positive review (and uptick in traffic) is lost.</li> <li>The person reviewing/specing the product is non-technical. This means they need fairly simple metrics by which to measure the capabilities of the delivered code.</li> <li>Throughput, load numbers, etc are easily quantified in legal terms. Thus a simple, unequivocal, enforceable contract can be written between developer and employer</li> <li>Lastly, it is very hard to produce lousy code that still performs well.</li> </ol> The issue of premature optimization is an internal concern for a developer, but it is never a concern that you will hear from a business owner. They just want to know if the code will met their needs. Hi Renat,

You are correct that not every website needs to be able to handle the load that amazon handles. And it is important for there to be reasonable expectations as to the needs. So when doing performance testing the simulated load needs to be inline with expected traffic.

However, consider these issues:

  1. The website may be highly successful, or be slashdotted/digged/etc. Being able to handle the ’success’ of a favorable review is critical. Otherwise, a positive review (and uptick in traffic) is lost.
  2. The person reviewing/specing the product is non-technical. This means they need fairly simple metrics by which to measure the capabilities of the delivered code.
  3. Throughput, load numbers, etc are easily quantified in legal terms. Thus a simple, unequivocal, enforceable contract can be written between developer and employer
  4. Lastly, it is very hard to produce lousy code that still performs well.

The issue of premature optimization is an internal concern for a developer, but it is never a concern that you will hear from a business owner. They just want to know if the code will met their needs.

]]> By: Renat Zubairov http://www.sworddance.com/blog/2007/05/29/thoughts-on-how-to-evaluate-code/#comment-8418 Renat Zubairov Sun, 07 Oct 2007 22:54:13 +0000 http://www.sworddance.com/blog/2007/05/29/thoughts-on-how-to-evaluate-code/#comment-8418 I wouldn't consider performance a critical acceptance criteria because you could get to the much painfull resuilts such as _PREMATURE OPTIMIZATION_ which is a bigger evil that badly designed SQL statements, or Vectors inside single-threaded environment. What I would consider most important is unit code coverage, if you don't have that you can't evolve, you can't put new developers on the source code without regressions. You wouldn't be possible to optimize the performance when it will be needed because of lack of unit tests. Also if we consider performance issues we should think about the fact, that actually big number of users is _very_hard to get in the first place :) I wouldn’t consider performance a critical acceptance criteria because you could get to the much painfull resuilts such as _PREMATURE OPTIMIZATION_ which is a bigger evil that badly designed SQL statements, or Vectors inside single-threaded environment.
What I would consider most important is unit code coverage, if you don’t have that you can’t evolve, you can’t put new developers on the source code without regressions. You wouldn’t be possible to optimize the performance when it will be needed because of lack of unit tests.
Also if we consider performance issues we should think about the fact, that actually big number of users is _very_hard to get in the first place :)

]]>