I dunno a lot of migrations to X technology are pitched as valuable on one quality dimension. We improved performance by Y%! When software “quality” should really consider many criteria: correctness, performance, developer productivity, maintainability and others.
I’d rather hear about a set of tradeoffs in these sorts of articles (performance was critical so we traded Y for X) than just bragging about one dimension of improvement.
I dunno a lot of migrations to X technology are pitched as valuable on one quality dimension. We improved performance by Y%!
I'd add that more often than not these performance impacts are not due to changes in programming languages/frameworks/libraries/whatever but because some architecture or algorithmic constraint is done under the scope of the migration.
Comments
I dunno a lot of migrations to X technology are pitched as valuable on one quality dimension. We improved performance by Y%! When software “quality” should really consider many criteria: correctness, performance, developer productivity, maintainability and others.
I’d rather hear about a set of tradeoffs in these sorts of articles (performance was critical so we traded Y for X) than just bragging about one dimension of improvement.
I'd add that more often than not these performance impacts are not due to changes in programming languages/frameworks/libraries/whatever but because some architecture or algorithmic constraint is done under the scope of the migration.