Dissidence between program leader and me, what should I do?

Question

Possible Duplicate:
How to tackle a boss who thinks everybody in this world is wrong except him?

I've been an MMORPG programmer for two years. I have some experiences on limited platforms like cell phones, so I've got a strong awareness of memory optimization. But the programs of my current company eat a lot of memory, neither server side fellows nor client side ones do not care about this matter, maybe spoiled by the memory industry growth. I've reported this issue to our program leader but he had nothing but scorn of my ideas, and he told me that we should do the client memory optimization when the project is almost releasing, and the server side memory occupation is not a problem at all, memory chips are cheap thus we could plug more if it's not enough. I'm really distressed about this parlance. We may waste memory everywhere if the leader don't advocate this optimization. This problem is a problem indeed in our released project that it caused low server FPS and client lag. My project is a still developing one. What should I do? Any suggestions is appreciated.

Answer 1

prove the value

or accept that it's just not a priority for them right now

possibly both

Answer 2

Both you and your program leader are partially right.

A program that leaks memory is indeed a potential problem if it leads to a process (plus essential OS support) taking up more memory than its host machine has physically available. In theory, you can live with it if the wasted memory is getting slowly paged out, but it too often doesn't work out like that in practice. Once lots of memory is getting shuffled to and from disk, performance is destroyed. Moreover, it can take quite a long time to hunt memory leaks (memory instrumentation is fairly expensive) so it's not a good idea to leave it to just before release, as it adds too much risk to the project schedule.

On the other hand, there's no point in putting stupid effort into memory leak hunting once you've got things down below the point where they're no longer a problem on the hardware available and time spent executing. Average memory availability is definitely increasing, and on the server side it most certainly is possible to calculate how much hardware to throw at the code.

So, there's no reason for conflict. You've just got different perspectives.

But that's not an action plan! What should you do? I suggest not having an argument over this (after all, you're both only partially right) and instead focusing on trying to make sure that the code you write doesn't have memory leaks in it. After all, it's ever so rare that a memory leak is a good thing! It's much better to get this right the first time. Take particular care when working with the client code, as that's much more likely to need to run in smaller amounts of memory and memory leaks there will have a greater impact on the customers' perceived quality of the overall system. On the server side, particularly focus on leaks in the critical service path as they'll hurt hugely in deployment. At the other end of the scale, a one-off leak (e.g., in parsing the server's config file) is not worth hunting at all. And don't go off hunting leaks in the code produced by other members of your team yet; you do need the agreement of your program leader for that and he's got to balance this task against all the other important ones that need doing.

Answer 3

You should listen to your programming lead. Optimize only when necessary, when the program works. And memory is cheap. If you can get 4GB for a hundred bucks and the problem is solved, it's not even worth considering to put just one single hour of work in memory usage optimization.

Answer 4

Your lead may be right to prioritize getting the behavior right before trying to improve memory utilization. Personally, I'd focus on behavior before I'd focus on optimization, since it's not always clear where the bottlenecks are at the beginning or even the middle of the product lifecycle.

However, there's nothing to stop you from raising your presumably well-reasoned concerns about the current state of the code by writing an analysis of the state of things as they are. If you can provide an assessment of the memory pressure, perhaps backed by performance tests, profiling, static analysis, or code instrumentation designed to detect memory leaks, you can build a case that there are technical and business motivations to invest in that area.

Each member of the team often brings a different perspective into the overall importance of a particular concern in the system. But you always have to weigh the tradeoffs between getting something shipping and getting the whole thing "right", by some definition of "right."

Ages ago in another life, I can recall spending hours trying to convince our developers to fix a bug that reliably caused an application crash every time someone tried to print a web page that had a Java applet on it, only on East Asian versions of Windows 95. It was high severity, but in the grand scheme of things, it was a low priority issue for the bigger goal of getting the browser out the door. My efforts didn't halt the release, but it ended up being a big enough deal that it got fixed (worked around, really) in the next release.

Raising the concerns with suitable evidence, without sounding unduly alarmist, will either result in investment in fixing the issue, or a clear statement from management that the problem is a risk they are willing to take. Either one of those outcomes is fine. You should be focused on working through the problems of your system; don't get too attached to specific outcomes.

Answer 5

+1 for focusing on a thing most developers dont even think about. As Steven Lowe has said you need to prove the value of memory optimization. Only when the cost justifies it will your manager agree. If you are using just 10 KB memory for an app and wasting another 10 KB it isnt a lot (even though it is 100% wasteage) becuase 10KB doesnt matter to a modern PC with 2-3gigs of RAM. On the other hand , if your application takes up 1GB of memory, even a 10% wasteage will be critical.

I totally disagree with your manager that opitmizations can wait till the release. Hurried, last minute optimizations may end up blowing in your face. If you feel the issue is going to be serious you will have to make a strong case.

Answer 6

Development Cycle Iterations:

1. Working correctly no bugs ( which means no memory leaks )
2. Stability ( re-factor anything that would cause maintenance issues down the road )
3. Performance ( only after profiling, includes optimizing memory usage )
4. GoTo 1

Performance is last because it causes risk and compromise to the first two. Performance tweaks can break things that are working, and can cause things to become un-maintainable.

Performance tweaks should only be implemented when profiling demonstrates a value in doing the work and out weighs the risk involved with modifying working stable code.

Fast incorrect behavior of the software is not a success.

Fast un-stable software is not a succcess.

In a nutshell your manager is correct.

Answer 7

The system will work fine while under development, even though the memory is not managed very well. Wait until there are hundreds of concurrent users hitting the application at the same time. Then it will crumble.

The bottom line is this and will always be this unless you work for the government. Sales Drives Everything. If this project is in development mode with only potential customers than it's a proof of concept. The goal at this point may simply be a working model to show to potential customers. Your not going to spend tons of man hours to make a perfect prototype.

The problem becomes this... when you show management that you have working model all they here is the word working. They have not idea that it's just a proof of concept. They start selling it and now, you have to scramble because all the memory issues you brought up start surfacing and the server keeps crashing.

Answer 8

All you can do is voice your concerns. In my experience nothing good will come from pushing the issue. Let him hang himself...