-1

While I subscribe to and usually work in agile workplaces and I believe have reasonable standards, I often find performance problems difficult in the 'heat of battle', and may put off or not get started on as quickly as standard features.

Despite building on general performance knowledge for some time, I'd like to know what I can do to start fixing and arrive at performance related solutions sooner.

Improve this question
2
  • 1
    Try site chat as this is really not a good fit for the main site.
    – enderland
    Commented Oct 9, 2015 at 16:35
  • You don't say how you go about choosing what to optimize. You're not alone - most programmers don't know how, and don't know they don't know. They are liable to think it has to do with cache-misses or big-O. Also, they are frustrated that the Agile methods don't seem to allow them to do performance tuning. I do a lot of performance tuning, but it can a frustrating experience just because most programmers don't understand it.
    – Mike Dunlavey
    Commented Oct 16, 2015 at 18:13

2 Answers 2

Reset to default
3

Your overall strategy during initial development should be to understand algorithms and data structures well enough to avoid writing code that is going to perform poorly by design.

For example, a triply nested loop with 100 iterations in each level may seem benign, but that's 1 million total iterations, and if anything is happening in that inner loop that takes any significant amount of time, then there's going to be a performance problem.

  1. Choose your data structures wisely. If you need O(n log n) lookup, then an ordinary linked list isn't going to cut it.

  2. Always measure first. Software developers are notoriously bad at telling how well code is going to perform just by looking at it.

  3. Only optimize when you're going to get a significant gain in performance. Where this happens isn't always going to be obvious.

  4. Whenever possible, optimize later. But don't fail to take advantage of those early design decisions that will insure your code performs adequately.

Further Reading
Back to Basics, where Joel Spolsky describes "Schlemiel the Painter Algorithm."

Improve this answer
0
2

Stop going rogue. You're making more work for yourself, and you're actually putting your job at risk.

Don't work on performance "problems" that aren't recognized problems. And as a corollary, the business will grant you time during the course of your regular work to address recognized performance problems.

  • If you believe an application's or feature's current performance isn't sufficient, is impacting other systems, or is a huge factor in high hardware or hosting costs, log it as a bug/request and let the stakeholders and product owner decide when/if you should spend time on it.
  • If there's a serious performance problem in the scope of a currently assigned task/story that would prevent it from being functional, it's not necessarily a "performance" problem at that point; it's a "the feature isn't usable yet" problem. Do what needs to be done to finish the feature using "best practices."

Anything outside those two reasons is extracurricular. It needs to be done on your time, and you ought to be really darn sure your optimizations don't introduce any bugs.

But, it's really just best to avoid doing work the company doesn't explicitly approve ... lest you have to explain how you were "just trying to learn some stuff" Friday after hours and accidentally lost a bunch of customer data or something.

Improve this answer
0

Not the answer you're looking for? Browse other questions tagged or ask your own question.