Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Should We Aspire to Optimize Code Everywhere?

DZone's Guide to

Should We Aspire to Optimize Code Everywhere?

No: premature optimization is harmful. But what about non-premature optimization? Still no -- unless the benefits are meaningful, which may mean >20%.

· DevOps Zone
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

Last week A [long] while ago I wrote a post about how I've seen a change in the places where it's important to write optimized code.

One of the responses I got was that "shouldn't we aspire to optimize [code] everywhere?"

" @mrlacey: Just Blogged: Where we write optimised code: then and now http://t.co/5h3vsV1aqC" shouldn't we aspire to optimize everywhere?
— Microsoft Channel 9 (@ch9) May 2, 2014

This strikes me as the result of a very developer/code focused reasoning and is, I feel, a topic worth discussing further.

Let's start by looking at this from a purely developers perspective. By which I mean we're only thinking about the code and there are no other considerations.

Given no other constraints then it may be fine to spend indefinite amounts of time on optimizing code. That is, getting it to run faster or use less memory or any other attribute by which we may measure code.

But to what end?

What benefit does such optimization bring? We may be able to say it's better but if that only benefits our developer mentality then is it worth it?

For most of the time there are external constraints when writing code. If writing for someone else (say as part of your job) there's probably a time and cost constraint. Either code must be written by a certain date/time or there is only so much budget to pay for the development effort.

Even if we are writing code for our own use then there will be a point when it's "good enough" to use. Yes we might be able to make it better than that but should we? If we want to keep making it better then at what point do you stop? If it's theoretically possible to make it faster do you put off shipping?

But what are we optimizing for in the first place?

Because we can?

Or because it will provide a measurable benefit?

On  .net rocks show #1003 there was discussion about the value of performance improvements and the following claim:

“The threshold of perception is 2%. The threshold of meaning is 20%”

This means that if you can’t make it 20% better (faster) then the user won’t care.

Do you really need to spend a lot of time optimizing your code for only a small performance improvement? Probably not.

But yes, also a difficult discussion to have when you have to optimize performance to hit some arbitrarily defined number. (If you've ever had a project where someone has decided that X must be done in 300 milliseconds and you're busy trying to get it down from 305 then you have my sympathies.)

Yes, performance is a feature and yes you should make things as good as you can. Just remember to balance them against being usable and good enough.

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:
code quality ,devops

Published at DZone with permission of Matt Lacey, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}