Product Manager: Customers will never up load more than about 50 MB of data
Engineer: Ok. I can have this done by the end of the week
Product Manager ( 5 months later): Customers are uploading 6 GB and wondering why it takes 3 hours. How long to make that faster?
Just about every programmer I know has some version of this story. If you have not had this happen to you yet, wait a week. Maybe two.
That being said, this is not going to be mandate, suggestion or general advice to always take the time and effort to make every piece of code you write to perform at peak efficiency. That will ultimately be a waste of time, cause deliverables to always be late and likely get you labeled as “really smart, but an incredible pain in the ass to work with.” Some people enjoy that. I never did. So with that in mind, and towing the line between doing things “right” and getting them done “right now”, Here are a few suggestions
- work with data sets two to three times larger than whatever you get in your initial requirements and make sure they work in the timeframe specified in requirements
- Timeframes have been specified in requirements, right? LOL JK!!! If this does not happen, and it often does not, keep these general guidelines in mind
- 1 second: Users stay focused, this is fine and feels responsive. Faster is always better
- 10 seconds: This feels like “a long time”. Your users will still be around, but they will be annoyed
- 1 minute: They are watching YouTube videos and have abandoned your application
- Timeframes have been specified in requirements, right? LOL JK!!! If this does not happen, and it often does not, keep these general guidelines in mind
- Test your code with all the expected data sets you can, and increase them to sizes and complexity that seem absurd at the time. Document how long these processes take and pass them along so when the inevitable request comes along for things “users will never do”, they are not a surprise
- Before delivering version 1, even if it performs to specs, run the code through a profiler. If there is any low hanging fruit, FIX IT NOW. There is oodles and oodles of research showing that bugs and issues are addressed more quickly and more effectively if they come up while you are working on or shortly after working on the code. You still have the context in your head. If the requests come in six months later, you get to go relearn all the things you forgot after having moved on to other projects. An hour or two now will save you a week later, and maybe those issues never arise a few months down the road
Performance is one of those pesky non-functional requirements (along with security, scalability, usability, reliability and maintainability) and always, always, always matters. As a professional engineer it needs to always matter to you and, in your professional capacity, you need to do your best to keep performance a concern you address while meeting all the other obligations of your job. The sad part about this is that, if you do your job well, you will never be aware of all the pain and sorrow you have saved yourself and your colleagues down the road because all of your software will “just work”.