pf » On Tradeoffs

November 09, 2007

On Tradeoffs

I don't think any other kind of situation pops up more in a programmers day to day work than a Tradeoff. Tradeoffs are everywhere and being able to identify and access tradeoffs I think is one thing that makes a great developer.

Here are some places you might see tradeoffs:

Performance Tuning - Any type of performance decision almost always involves tradeoffs. It wouldn't be tuning without some tradeoffs, else you could just press the Turbo button (remember those?).
User Interface - There are tradeoffs involved in creating a great user interface as well. Deciding which features should be emphasized and which should be less subtle are key to creating a good interface.
Database Design - Sure you could normalize every entity but it may take you a week to write SQL statements that join 12 tables. Likewise you don't want to waste space, and have performance issues if you don't normalize enough. You have to be able to find the sweet spot.

What tradeoffs do you face? And how do you make tradeoff decisions?

Permalink | Add Comment |

add to del.icio.us | Tags: tradeoffs, performance, design, software

Related Entries

Usability vs User Experience - June 28, 2006
Performance of database tag schemas - June 20, 2005

This entry was:

Trackbacks

Trackback Address: 658/CD1FD404AEB17B8293D01569EDE0D4E9

Comments

On 11/09/2007 at 9:32:25 AM MST Ben Nadel wrote:

Here's a thought on tradeoffs that you might give some feedback on; totally normalized addresses. Let's say an item in a database can have multiple addresses (1 contact :: N addresses). Normally, I would have a contact table, an address table, and one that relates the two.

But what if a contact should have a *primary* address. This is the one that will be used in all the reporting and lookups and what not. Normally, I would have some field in the Address table like is_primary.... but as of late, I am feeling like this makes things more complicated than is worth the payoff... now, I am thinking that the Address table should ONLY be for *secondary* addresses and that the COntact table itself should contain the PRIMARY address information. This way, if all you care about is primary address info (ex. get all contacts who live in zip 10011), you don't have to join tables.

Plus, there is something very nice about knowing that a primary address record always "Exists".

Thoughts?

On 11/09/2007 at 9:44:57 AM MST Pete Freitag wrote:

The down side of that approach is that you have to write more code to store the secondary addresses because the code used to store the primary address can't be reused directly, like it could with the other approach. Also if you do need to pull in all addresses primary and secondary in a particular zip, then your query just got more complicated.

But if you are doing a lot of reporting on the primary address, it might be worth the extra work to manage both address storage locations.

Tradeoffs are often very difficult decisions. You must have a deep understanding of the requirements to make a good choice. There isn't always one right answer either, so don't beat yourself up too much down the road if you realize you made the wrong decision.

On 11/09/2007 at 9:55:38 AM MST Rob Wilkerson wrote:

Off the top of my head:

Readability vs. Performance I'll almost always opt for readability at the expense of some level of performance, but sometimes that line gets crossed and future developers will just have to suck it up.

Extensibility vs. Performance I prefer to design for extensibility and code for performance (not my phrasing, but I can't remember where I read it). Every layer of abstraction adds some measure of overhead, but if you don't take the hit now you'll be really, really mad at yourself next year when you want to add that cool new feature that just won't fit into your monolithic architecture.

To summarize:

Now vs Later Right now I just want it to be done and to function properly. Later, I want to be able to easily maintain it, add new features and update my business logic without a lot of redundant effort or a massive overhaul.

On 11/09/2007 at 10:25:34 AM MST Ben Nadel wrote:

Thanks for the feedback. I think part of where I am coming from is an issue of poor data management. I work on some systems that have horrible data and relationships that have 1:N where N must be 1+ are not always upheld (meaning, relational constraints are not always valid). So, to deal with that frustration, I would love to have all *required* data in the same row.

But, I think if I was working with a better data set, the standard join table would be fine.

On 11/09/2007 at 11:33:57 PM MST Azadi Saryev wrote:

@ Ben: just a thought - if your application allowed, as a feature, the users to select & change their primary address, including an option to select new primary address from existing secondary addresses, while saving current primary address as new secondary address... am i making sense here? would you then store an id of an address record from Address table in a primary_address field in Contacts table? love your KS, btw.

On 11/11/2007 at 8:44:27 AM MST Ben Nadel wrote:

@Azadi,

You are correct. I guess I was just reacting to a poorly thought out and maintained data set that I have to work with now. I think, had things been designed a bit better, I wouldn't even be questioning the join table, which in my gut, I know is the right way to do things.