two-pot screamer dot com

From Slashdot | Twitter Reportedly May Abandon Ruby On Rails

Does a clean architecture matter? (Score:5, Interesting)

by BadAnalogyGuy (945258) <BadAnalogyGuy@gmail.com> on Friday May 02, @11:51AM (#23275608)

I have an argument with a coworker frequently about architectural orthogonality vs performance. I fall on the “architecture should be clean and easy to understand and maintain” side of the argument and he falls on the “speed, memory, and response time at all cost” side.

What is more important? Is developer time and productivity over the software lifetime more valuable than CPU cycles? If the price of that productivity imposes a maximum limit on performance, how much optimization should be undertaken?

It’s a hard question to answer. On the one hand employees are expensive and hardware is cheap. On the other hand, you can’t simply forego developing for performance just because of some religious belief that architecture should be clean.

Re:Does a clean architecture matter? (Score:4, Insightful)

by samkass (174571) on Friday May 02, @01:12PM (#23276740)
Homepage Journal

While system responsiveness is often a product of optimization, scalability rarely is. When a system can scale across orders of magnitude, it’s because of a clean, maintainable architecture that allowed components to be completely revamped and swapped in, identified and eliminated high-polynomial (or worse) growth patterns, and allowed more developers to be spun up on it fast enough to keep up with demand.

On the other hand, if you spend all day pondering the ultimate architecture, you’ll never ship and if you do you won’t meet requirements. Learning where those tradeoffs are is all about experience and is why the engineers with over a decade of real world experience earn more.

Re:Does a clean architecture matter? (Score:4, Insightful)

by bill_kress (99356) on Friday May 02, @05:41PM (#23280078)

Premature Optimization is the root of all evil.

I’ve never seen anything saying otherwise.

Follow any of these sets of rules:

http://c2.com/cgi/wiki?RulesOfOptimization [c2.com]
http://schwern.org/~schwern/talks/What_Works/What_Works/slide016.html [schwern.org]
http://www.cs.cmu.edu/~jch/java/rules.html [cmu.edu]

Or my version–
1) Don’t optimize, no really, don’t.
2) If you absolutely have to, write it unoptimized, test it, write it optimized, then:
2a) If the first is anywhere in the ballpark, throw away the second,
2b) If the second has enough of a proven, documented speed gain to get you past some accept/no accept barrier, comment out the slower one, but keep it so the next guy can follow the “Good” code.

If you don’t document exactly what you did in the code and why, I’m going to refactor it into something readable the second I see it.

Also–know how to program. Choosing a linked list instead of an array list for an insertion sort is just programming correctly. It’s not an optimization.

-1 offtopic… Just wanted to help the parent out with his cow-orker.

This entry was posted on Saturday, May 3rd, 2008 at 8:56 pm and is filed under Scrapbook. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.