Every developer has a set of bias that drives their development. A developer’s bias determines how they write code and what they consider is good vs. bad code. I believe there are few if any "well rounded" developers that provide equal weighting on all areas; that’s why having a team of developers with different bias can be a good thing (or they can tear each other’s eye-balls out, depending on the mix!)
For many, absolute performance of every line of code seems to be an overriding factor. Lately, a lot of developers have (fortunately) become focused on testing. Others focus on user interfaces; some on making them beautiful and others on making them usable. Still others consider security of utmost importance. And there are many areas I don’t mention here or below (if your area of bias wasn’t mentioned, please tell me about it in the comments.)
My personal bias is strongly towards architecture. For me, an architecture that provides maintainability (small functionality updates mean small code changes) followed closely by elegance (consistent naming and orthogonal design) and enablement of "RAD-ability" (standard patterns contained in a framework.) I have further bias towards resiliency (adaptability to change), robustness (graceful handling of unexpected conditions), correctness (ensuring correct logic and interaction), and minimized yet explicit coupling (subsystems communicate in few, well-defined ways.)
When I say I have biases towards the above aspects of architecture, I mean when a tradeoff must occur, I will choose architecture over, say, performance. That doesn’t mean I don’t want performance, but I won’t sacrifice architecture unless absolutely necessary. And I am pretty sure I’ve had these biases since I first started coding. Over the years I’ve learned that several of the aspects I mention are opposing forces, such as RAD-ability and resiliency. So I’m always trying to balance goals.
Why do I blog about this? First, as a background piece for future blogs I plan to write. Second to state that development goals are often at odds with one another, though that should be obvious to any developer.
And third, to point out that most disagreements about which language to choose or how to implement something are driven by developer bias. Without knowing a developer’s bias is it is hard to appreciate their arguments and come to a resolution. But more importantly, I believe every developer should contemplate their own biases because doing so will help them become a better developer overall.
P.S. As I was finishing this piece this post from Rick Strahl ironically just popped-up on my SharpReader about how some developers avoid .NET Reflection for perceived performance reasons.
This is a very good point actually. I find myself in much the same boat. I think my bias lies between elegance and performance which are often two contradictory terms as abstraction that provides better usability and maintenance usually has a price in performance. It’s all in the balance of things.
But on the other hand I see a lot of misguidance in relation to performance in many places. People counting method calls, referencing of many nested static class properties and so on. Yes there’s a time for bit counting and wrenching every bit of perf out of a routine, but in 90% of the cases the performance is a) not needed and b) probably not even noticed… That’s what you get when too many C++ programmers get invovled in a language, he he…
Thanks for the comment Rick. Obviously you’ve got no disagreement from me! BTW, you have a great blog and I’ve been planning to post about why. I will soon.