CODING TO PERFORMANCE: MENTAL TORTURE FOR SOFTWARE DEVELOPERS I’m messing with t

CODING TO PERFORMANCE: MENTAL TORTURE FOR SOFTWARE DEVELOPERS

I’m messing with the team lately:

“Speed is a design pattern too.”

“So, I don’t care if its easy to program – I just care if its fast.”

“Yes it’s painful. But I pay you once for pain. The user feels pain every time he loads a page. In the pain-economy, you’re pain is just a better investment.”

🙂

A good complier in most languages will compensate for the overhead of writing ‘good clear code’. But we are increasingly using languages that aren’t put through ‘good compilers’, and as such, we can’t afford the high cost of that overhead.

We coded our product for performance. And the price for that lack of overhead is readability. That means that the code is a bit hard to read for a new employee – it’s hard for me at least.

But, in exchange, I’ve been very happy with our performance. One competitor I’m very familiar with generates about 50MB of peak ram on the server. Our same feature generates just over 4MB of peak memory on the server. We only load what we need for any given request. I think we’ll get to 5MB a request before we’re done. Between the various tactics we use (rarely reloading the page, if ever) only loading sections of any page dynamically (like FB does) , and fetching the data from the client side after the page is presented – all of which are pretty standard fare these days – we have an amazingly fast application both statistically and perceptibly. So coding to speed worked for us.

The truth is though, that clear code is easier to debug, and easier to maintain. And it’s harder for bugs or un-executed code to creep into the source. But in exchange, adding devs to the product team is difficult. And programming to performance is in itself, slow for these reasons. And our application isn’t small by any means.

It is, really, much more dense and full of features than the previous generation of ERP/PSA systems that run on desktops. (They look ‘child-like’ to us at this point. Really.) So we have to be very conscious of performance, and conscious of the fact that browsers tend to bleed memory like crazy.

At present we’re testing out switching ORM’s (the software that maps the program to the database so that developers don’t have to write much SQL) to see if we can make the code easier to write without much of a penalty. But we can’t seem to find a script solution for the browser side that is mature enough for our needs, and is as fast as the way we do it today. It’s better than it has been, but it’s not there yet.