I’m at the Much Ado About Agile conference this week, in beautiful Vancouver. During lunch one day, one of the conference participants started talking about premature optimization of code.
Well, I know a few things about that. When I started to work professionally as a developer, I wrote in assembly language. We had 256 bytes per page. You had to leave a few bytes at the end so you could insert a branch (goto) in case you ever needed to patch the code and insert more functionality, or go to another page. Optimizing your code was a reasonable approach.
I later worked on process control or instrumentation systems, where the software footprint was bounded by the memory in the embedded system–not much, although I no longer remember how many bytes. Since memory was measured in kilobytes, not megabytes then, it couldn’t have been many. Optimizing my code was necessary.
Ok, so that was in the 70’s and early-mid 80’s. Once memory started becoming less expensive and disk drives decreased in size from washing machines to thumb drives, we don’t have to optimize code in the same way.
But there are plenty of reasons that people still optimize. The first is habit. The second is belief that if you don’t build in the optimization at the beginning, you won’t be able to. There must be a third, but it’s too early in the morning for me to remember right now.
We bring our contexts with us, throughout our careers. Sometimes those contexts no longer fit.
When you notice something about the way a colleague is working, try curiosity before labeling that colleague as old-fashioned, or stupid or some other label. My lunch colleague had never realized that people who were still alive (!) worked in assembler, or had to optimize their code, or that linking-loaders actually existed. He thought that was waaay in the past. Yes to the past, but not to the way past.
Our project decisions are based on our context. The challenge is to make sure we are using the context that fits.Tags: context, project