views:

339

answers:

14

Ahhhw, every time is so frustrating..

We have a dedicated server in our hosting company, and everytime i have to write down a new app (or an add to an pre-existing app), i use to 'lose' some time to optimize the code for many behaviors (reducing the db query, optimizing the db structure, reducing the bandwith, etc..) depending on what the app is supposed to do.

Obviously, is the point is not that i write bad code and then rebuild it, its just that after the project is complete, i allways find somethings that could be done better.

And everytime, if my boss catch me doing this, he say 'Your wasting your time! if the application need more resources, we buy more RAM, more CPU, or more bandwith!'.

What is the best (and simplyest) way to explain he that optimization is still important, and that is not so easy or automagically upgrating the hardware of an (production!) server?

EDIT: im not talking just about database optimization, but every aspect of an application

+6  A: 

Keep detailed notes and time sheets the next time you make a server move/upgrade, and protocol every minute of work that arose from it (including things in the weeks after). Then you'll have hard evidence that upgrading is expensive, and optimizations help delay the investment.

In the current situation, you might be able to do something with benchmarks and statistics along the line of "without my optimization, the server will be at 90% capacity with X number of users. With my optimization, we can cater for Y users more, before we have to get a new machine."

On the other hand, the line between optimization and over-optimization is thin. While writing code that doesn't waste resources is good craftsmanship and should be a human right, RAM and disk space are awfully cheap these days. Optimizations also tend to make code more complicated, and harder to maintain for others. When you control your own hardware, code optimization may not always be the top goal.

Pekka
This is one of the few answer that really answer the question ;)
DaNieL
+3  A: 

Wait until buying RAM and CPU becomes more expensive than paying you to optimize the code. Then you have a case.

Just you wait! The next oil crisis may be a silicon crisis. :)
Pekka
Good one, although it could be argued that adding servers and CPU's contributes to the former. :)
Turnkey
+15  A: 

Chances are you are really wasting time. Most of the optimizations that you learn in college or university are sort of irrelevant in the business world. I recommend concentrating on those optimizations where you can quantify WHY your optimization is worth your company's money (your time spent is their money spent).

Thorsten79
Reducing the monthly bandwith of 35% in a website, speed up the db querys about 20-40%. Optimizing the request to reduce the numbers of needed requests itself to do an determinate things.He complained when saw me wroting an app to compress all the db.sql backups on the server in a single .gz file! 2 hours of my time reduced the disk space used by the backups of 50%!
DaNieL
Disk space is almost free nowadays. Programmer time is not.
anon
Does your boss know anything about running a data-centre ?
Hassan Syed
@neil Relational database backups and relational database disk space is not free.... at least not if your dealing with terabytes of data -- perhaps in the case of nosql clouds. Once you hit the limit of the amount of disks/ram you can plug into a single machine that's ussualy it -- game over (unless you have a large investment up-front into creating a plug-n-play database aware application).
Hassan Syed
@Hassan I know you have difficulties understanding my posts here, but you did notice the word "almost" in my comment? And for your information, I've been dealing with relational databases since 1985.
anon
@DaNieL: If you have made substantial improvements that have saved time and money but NOT been rewarded for it, either your management sucks (which is NOT normal. Management has a purpose contrary to some programmer's impression) or you have not COMMUNICATED your improvement properly. You have to talk business, not tech. Non-tech managers will filter out the tech-talk off your argument. If nothing is left then, you lost your case.
Thorsten79
++ about optimizations you learn in college. Reality is completely different.
Mike Dunlavey
what if i say that i'd never been to a college?
DaNieL
@DaNieL: What if I say I taught there? (I did.) **gprof** is a good example. Its big innovation was that it builds a call-graph. Academics love graphs. You have to read journal articles to get things like connected subsets and minimal spanning trees. Those are challenging and interesting, therefore fun. Never mind that they're **irrelevant** to the problem.
Mike Dunlavey
... Another example is some of the challenging and fascinating optimizations that compilers do these days, like loop hoisting. It's easy to *imagine these things actually help* if one doesn't know the first thing about real performance tuning, which is something you need to learn in the real-world.
Mike Dunlavey
Everyone is saying the same thing, if you aren't making or saving the company money you are wasting time. Saving disk space if the disk isn't near full is NOT saving the company money. If you are speeding up something by 40% that MEANS NOTHING if the time is in milliseconds already. If you are not hitting your bandwidth limits and paying extra reducing bandwidth usage is wasting time. Ad nauseam.
fuzzy lollipop
@fuzzy lollipop: i cant see it like that. If im saving 40% RAM on the server, it means that the server can host other projects, and we dont need to buy a new one. And anyway, this question is about 'how to explain', not 'is saving X% of `something` worth the time?'
DaNieL
+1  A: 

If you are on a relational database (and your not working with trivial applications).... you cannot afford to write bad database queries. Since you are you using a red-gate tag I assume you are on SQL server. If you design a bad schema (including querries) on SQL Server a database server when you start getting moderate traffic you will be forced to scale in horrendous ways. Once you get a high level of traffic you will be screwed -- and will need to hire a very expensive consultant/DBA to undo the mess -- use this arguement with your boss :D.

What I am trying to get at is even though SQL is declarative and it doesn't appear that you have to pay attention to performance -- it doesn't really work that way. You have to design your data model by keeping in mind the way it is going to be used.

If you are writing business logic in application code ... well that doesn't matter much -- you can fix that latter with less trouble if performance becomes an issue. Most business logic these days is stateless (especially if its web-based or web-service based) meaning you can just chuck more machines at the problem -- if it's not than its just a bit harder.

Hassan Syed
dont know what the rg tag means, i just used the performance tag.. anyway, im running 40% mysql and 60% postgresql, hoping to reach 100% postgresql in the next 1-2 years.
DaNieL
'Once you get a high level of traffic you will be screwed -- and will need to hire a very expensive consultant/DBA to undo the mess -- use this arguement with your boss :D.' - this is a good point, but i fear that if this will ever happen, my boss answer will be 'you designed bad the database'
DaNieL
The "rg" just means that Red Gate have sponsored the [performance] tag.
ChrisF
@daniel and @Chris thanks for the tag stuff :D -- well there is one good thing about using open source databases -- you don't have to pay a 6-10 k £ licence fee per db-server :P.
Hassan Syed
..and you'll find much more support and answers around the world (that you then need to skim between good and bad answers ;)
DaNieL
A: 

Every time something takes long than it would have if the refactoring had been done ahead of time make sure your boss hears about it.

runrunraygun
can explain better? dont understand that answer..
DaNieL
+1  A: 

Optimizing is often really just a waste of time, what is more important is optimizing for maintainability:

- keep the code simple (see: KISS)
- move duplicate code into functions (see: DRY)
- optimize comments (as few comments as possible, as many as necessary)
- remove unused code

Those changes do not necessarily affect the speed of the program but they reduce the time needed to implement changes and fix bugs so they have real business value as they save expensive developer time.

dbemerlin
...ehm... the 4 points you have said are a part of my normally optimization (except for poin 1 and 2, i optimize the code in that way while i wrote it)
DaNieL
In that case your code is optimized enough and should only be touched when you encounter something that takes more time to execute than you need to fix it and which gets called often enough to _seriously_ reduce the effectivity of those using the software, which is rare. Remember: One developer day costs your business roughly enough to buy a new server or at least a few GB ram.
dbemerlin
+1 for "optimizing for maintainability".
peterchen
Maintainability is very important, goes without saying and should be part of developing. However, the flip side is there's no point having a very easy to maintain application that performs like a one-legged donkey. What the end user experiences is crucial. Plus, you have to think about scale. A slowly performing bit of code/query may take longer to fix for the dev than it takes to run. But over 100, 1000, 10000 executions it all builds up to an overall bigger problem .
AdaTheDev
@AdaTheDev: I think you can have maintainability and performance together - they are not in a tradeoff relationship. I try to write maintainable code (though my co-workers might disagree) and optimize second. Usually the optimization has either no effect, or a beneficial effect, on maintainability.
Mike Dunlavey
@Mike, yeah that was the point I was trying to make - instead of just optimising for maintainability, you should also be thinking about performance. Just trying to make the point that performance is as important.
AdaTheDev
+1  A: 

If you're having to explain why there is a need for optimisation, then you're already on a low-win-rate path. Unfortunately, the best argument is when there is a situation where performance is becoming a noticeable problem (e.g. customers complaining) - this makes people sit up and listen if they're getting constant ear-ache about it. Often, the solution can be that throwing hardware at it is the best/cheapest solution.

However for me, performance is important, when working on highly scalable systems, you need to spend time on optimisations. It should at the very least be on your mind while you're developing and a lot of things can be swallowed up in the dev process (as opposed to after you've finished, then going back to optimise).

e.g.
- What happens if my database has 100,000,000 records instead of 100,000? (you can easily fool SQL Server into thinking there are more records in a table than there actually are to see what the effect on the execution plan would be).

If you're being pro-active about optimisation (which I personally think is good), then you need to try and come with a real-world meaning to your boss. e.g. "if we optimise our site by cutting down the page size, we could save x amount of bandwidth a month, saving us xx much money".

You do have to be careful about micro-optimisations though as you can micro-optimise until the cows come home, for much lower benefit.

AdaTheDev
A: 

IMO, It's less a case of convincing that optimizations need to be done (and based on your Boss's responses, you're not going to win this fight), and more a case of always building in refactoring time into your estimates.

Bob Palmer
+5  A: 

Do you have performance objectives for the application(s)? Free capacity, response time, bandwidth usage etc. Without them you will find it difficult to justify why an improvement needs to be made. You need to be able to quantify the problem before people will spend money on it.

If the application is already meeting the requirements then your boss is probably right.

To ensure reserve capacity for future customers you (and your boss) could set a threashold such that once performance comes within a percentage of the requirements you need to investigate the problem. This is the time for you to request/push/negociate for performing optimisations as he will be aware of the problem and the risk of doing nothing. If you can recommend some changes to correct the problem that will cost less than the hardware then hopefully he should agree to let you do it. Of course the reverse still applies. If the total cost of the hardware upgrade is cheaper then that is probably the better option.

Aaron
+1 very good points!
Pekka
+1, somewhat agree
DaNieL
+1  A: 

You could just wait until your boss says "Why is it taking so long?" Then you could say "Hey, boss, we could buy 10 times as much hardware, or I could spend a couple days and make it 10 times faster". Here's an example.

Added: If your boss says "Well, why did you make it slow in the first place?" I would have no trouble explaining that he could hire God's Right Hand Programmer, and the code as first written would still have room for optimizing.

Mike Dunlavey
And yes the more servers you have the more expensive the room to keep them in is. At one job we had to add two very large, very expensive air conditioning systems and had to have some very expensive electrical work because our boss figured we could just throw more hardware at the problem becasue hardware is cheap. And who knows how much higher our electic bill became. At another job, we would have had to rent more space because the server room was in a closet and was full. I left there before it became an issue, but I'm sure it has by now.
HLGEM
Yep, and I remember 15 years ago seeing a Cray in its special building, with its ECL logic modules connected by twisted-pair wiring tuned like a radio, with its freon waterfall cooling system, costing incredible bucks, and realizing that it was quite possible that the code running on it could easily be slower than necessary by an order of magnitude.
Mike Dunlavey
+2  A: 

There's a break even point between improving software vs. improving hardware. For desktop systems, a good threshold is by purchase time:

If that machine fails, can you go to the next mall and buy a replacement within an hour?

As long as you can answer yes, optimization is futile - an investment into the future maybe, but is that really your decision alone?

A similar rule for web sites might be "how long would it take to get a new hosting contract on that?"


This isn't perfect, it covers just a single aspect of scalability. I like it because it's an easy to understand aspect outside of technical concerns.

Of course, you should have more material if that aspect suddenly gets brushed away. It helps to just ask what are the companies/bosses plans for a few key scenarios. - e.g. what contingency plans for DDOS attacks, for "rush events" etc. Having some data to back that up, some key stories ("company foo was mentioned on popular night show, web server broke down under requests, business lost, potential customers angered") helps a lot.

The key to realize is that (assuming from your description alone) it is your responsibility to forsee such events, and provide the technical solutions, but it's not your responsibility to mke these decisions.

Also, getting a written statement from your boss that "five hours downtime isn't a problem, get bck to work on the important things!" is a good CYA.

peterchen
+7  A: 

When trying to optimise code you need to follow the optimisation cycle. There are no short-cuts.

  1. Define specific, detailed, measurable, performance requirements.
  2. Measure your application's performance.
  3. If it meets the requirements, stop, as continuing is a waste of time/money.
  4. Determine where the bottleneck is (which machine? CPU, memory, disk, etc.?).
  5. Fix the bottleneck (either hardware or software fix, whichever is faster/cheaper).
  6. Go to 2.

From your post it doesn't sound like you have done 1 or 2, so you've skipped over 3 and 4 because you don't know enough to do them, and are now stumbling blindly around in 5 attempting to optimise whatever you think needs optimising.

So from what you've said I'd have to agree with your boss. You are wasting your time. Or at least you haven't followed enough process to prove otherwise, which is essentially the same thing.

Greg Beech
+1, and this answers the follow-up question here: http://stackoverflow.com/questions/2125559/when-the-optimization-really-worth-the-time-spent-on-it.
Jeff Sternal
A: 

Do a cost analysis...

This will take me X hours and will mean every project needs 50% less data storage. Based on us doing 2 projects a year using on average 100Gb space, that will save $Y after a year, $Z after 3 years.

Crude example but it suffices.

Ultimately you and your boss are both wrong... you think code has to be fast (primarily) to satisfy your idealism, he doesn't care at all as he wants to deliver products.

John
+1  A: 

about the same way one would explain a developer that code/resources optimization is unimportant ...

i guess this problem arises because your way to measure importance is different than his ...

his job is to care about money and make sure he gets the "most" out of it ... and frankly, servers are cheaper than developers ... and managed servers are cheaper than admins ... and the ugly truth is, that many people think that way ... personally, I think PHP isn't really the right choice for performance-critical parts of an app ... neither are RMDBSs ... but nearly every managed server runs PHP and MySQL and business clients prefer to have an app they can run everywhere, based on a technology widely known, which turns out to be PHP and MySQL on the server side ... the world is a cruel place and the truth is ugly ... now when it comes to you, you have only 2 choices:

  • live with it
  • work with people who are more like you, and who share the same ambitions

your boss does the job right, from his perspective ... what you do is a waste of company money, because the company's goal is not to write beautiful and highly optimized code ... whatever your company does, in the end you only provide a tool ... and the value of a tool is measured by the use it provides in relation to the money it costs ...

if your optimizations were economically reasonable, then the easiest way would be not to optimize anymore and wait for the moment until your boss comes to you, asking for speedup ...

i suggest, you either look for a new job, or focus on other important things:

  • good design and use of best practices such as KISS, DRY, SOLID and GRASP
  • scalable architecture (doesn't mean you have to actually implement it, just have an idea how the whole thing could scale well)
  • maintainability, including readability and good documentation
  • flexibility & extensibility
  • robustness & correctness
  • do not reinvent the wheel and use the right tools for a job - use adequate technologies, libraries and frameworks
  • fast developement

these goals are important for the present and the future of a software project (also when it comes to money (especially the bold ones)) ... and they provide the possibility of doing optimization when actually needed ...

this probably isn't the answer you wanted, but I hope it helps ... ;)

greetz

back2dos

back2dos
Surely, a server cost less than a developer. But if the application crash out becose the db schema isnt optimized, and you lose some customer's data? If soon or later the application get slow?Losing customer will cost too ;)
DaNieL
@DaNieL: if you use a proper SQL driver with a robust, transaction-safe storage engine, you don't lose customer's data just like that. and if you want your app to be reliable and fault-tolerant, than optimization isn't the first thing to do.you have to ask yourself one question: did any problems occur yet? presumably not, otherwise you wouldn't have this discusion. because really, you could put the DB to an extra server, put the backup on an extra server or whatever. or just move to ec2. i understand your idealism, but materialistically, your boss is right. as i said: you've got 2 options.
back2dos