We recently had a discussion in the office because of conflicting views between developers. One side (side S) argued technical solutions -generally- need to be a specific as possible, while the other side (side G) argued generalized solutions are preferred.

I'll try to keep it short; we deal with file transfers and we need to start saving three files (log.txt, details.txt, receipt.pdf) for each transfer. We already have a files table that we'll use but we all agree that we need a different table to create a one-to-many relationship between transfers and files.

Side G proposed creating general resource_attachments table that can attach files to any type of resource it would look something like this;
- id : int
- entityId : int
- entityType : string
- fileId : int
- kind : string

Side S disagreed and proposed creating a specialized transfer_attachments table, something like this;
- id : int
- transferId : int
- fileId : int
- kind : string

One argument of side S is that any resource should be as specific as possible so its role and its attributes and their possible values are clear, so any new developer will have no trouble understanding it.

An argument of side G was that a more generalized approach would provide a broader range of functionality; you can attach files to any resource, whatever their role will be.

Though the practical differences are very small, there is some fundamental stuff going on here (this is where it gets philosophical); one person in the room sharply observed that the generalizer is the ruby expert, while the specializer is the java expert. Ruby is an interpreted language with dynamic typing while java is a compiled language with static typing.

I found the matter wildly interesting and was wondering which approach is preferred; specialized or generalized solution, and what matters should be taken into account?

Note that we're only talking about a the technical part of the solution, this has nothing to do with the end-user experience.

  • perhaps generalized code, specialized schema?
    – rwong
    Commented Feb 17, 2012 at 10:02
  • @S.Lott I guess my question was to have opinions and insights on the specialized VS generalized approach, and which of the two is desired in what situations.
    – mark
    Commented Feb 18, 2012 at 17:03
  • @S.Lott I edited the question, my excuses
    – mark
    Commented Feb 19, 2012 at 11:40
  • Please do not cross post to multiple sites. If you get the wrong one your question can, and will, be migrated. Duplicate posts cause work for the volunteers who help run the sites.
    – ChrisF
    Commented Feb 21, 2012 at 9:02
  • @ChrisF Yea, sorry I got a message that this question belonged on this site instead of stackoverflow, but I didn't know that it would be migrated automatically.
    – mark
    Commented Feb 21, 2012 at 9:12

3 Answers 3


As usual, the answer is: it depends. There are lots of issues to consider, including:

  • first and foremost, what the customer wants and is willing to pay for
  • the difference in implementation and maintenance cost and risks between the alternative solutions
  • the expected lifetime of the product
  • the expected scope of future changes (i.e. is it reasonably expected that the more general solution will actually be used in the foreseeable future?)

If the more general solution is easy to implement, with minimal additional cost and zero risk, it may be a good idea to do it, even if there is no known need for it. OTOH if the general solution is significantly costlier, you need a strong enough justification (= added value for the customer) for it, otherwise you end up with speculative generality.

You should always keep in mind that a more general solution usually (although not always!) means more complex code, which is thus harder to understand and modify in the long run. So the implementation cost is not the only factor to take into account. Maintenance costs for a product with a long lifecycle exceed development costs manifold. OTOH for a product meant to be used only once or for a short time, obviously making it more general may be pointless. (Although we should be aware that the actual lifetime of software is often significantly longer than originally planned.)

And the "not always" case mentioned above also includes cases when careful analysis of the problem reveals that it is a subcase or a different view of some more general, well known problem for which known solutions exist, or the solution is significantly easier to implement. In these cases, the extra analysis and design effort more than pays off in simpler and cleaner code, which may even be faster and/or less resource hungry. These cases are the exception, rather than the rule, but still they are worth mentioning.


One extra aspect I forgot to mention is the potential cost of making the solution more general in the future. Often it is not significantly costlier to refactor the code later than to make it general now - which suggests deferring the decision to as late as possible. The economy of such decisions is saving 100 dollars now, with the risk that in the worst case, you will need to pay 110 dollars some years later (but you have invested that 100 dollars and it may have since earned you more than that), but in the best case you pay nothing.

However, there is (at least) one area where refactoring later is significantly costlier, riskier and more difficult than designing a general solution from the start: databases. Changing your table structure and migrating huge amounts of business critical data into a new structure is far from trivial even in simpler cases, and can be downright impossible sometimes. So when designing a DB schema, it makes sense to go for the more general solution, which can include a greater range of potential future extensions.

  • I like your point that a generalized solution is especially meaningful when it ties into a well-known pattern and I definitely agree that generalized solutions have a greater risk of growing complex. Now, to rule (initial) cost out of the equation let's assume that the practical difference between both solutions is minimal. Would you say that vagueness surrounding the possible values for the kind column renders the resource_attachments table in the generalized solution more complex than the transfer_attachments table where the possible values are clearly log, details and receipt?
    – mark
    Commented Feb 18, 2012 at 20:56
  • @user1214751, sorry, but I know way too little about your case to be able to answer this. In general, I do prefer the simplest solution which could possibly work. However, DBs are different from e.g. Java code; see my update above regarding this. Still, I have not the faintest idea about the probability of solution G above to actually become useful in the future. Only you can assess this. Commented Feb 18, 2012 at 22:59

For a good start to reading see this wikipedia list. Ideally, you are looking at separation of concerns. While a more general solution has advantages for reuse between projects, there is a problem.

The database is concerned with storing the data, and so it is the job of the database to know what the data is. You don't want a table that can store anything with one field holding the data and one holding the description.

I would follow the rule of representation. The data needs to say what it is, or else it is useless. Only if the data is actually general should it be treated as general.

Finally, worse is better. You aren't going to know everything about generalizing the solution when you first build it. You don't know what is actually required, so building a solution that attempts to do so is far more work for only a marginal gain.

  • Thanks for the links, this is very useful and I 100% agree with you on the rule of representation comment.
    – mark
    Commented Feb 19, 2012 at 11:52

My answer ultimately is similar to Péter Török's in that I believe it depends on the additional effort and complexity of implementing the Generalized solution.

Framing this as a implementaiton argument though is a mistake, and labeling the two opposing sides by programming language and defining that in the way they think is dangerously close to creating the stereotype of the logical, forward thinking Ruby developer versus the trollish, stubborn and foolish Java developer.

This shouldn't be a technical discussion in how to fulfill the needs of the client with the added anticipation that clients almost never really know what they want and change their minds frequently, and also expect that when they change their minds it won't result in a major refactoring effort. This problem isn't so much about seperation of concerns (which is important on its own merits) in my mind, but one of realistic interpretation of reality.

If I am modeling a strict interpretation of the Mayan Calendar and designing and implementing it strictly then I am probably right to be specific in my design. I am virtually guaranteed that the Mayan calendar will not change, especially seeing as how the Mayan people no longer exist on this Earth. On the other hand if I am designing a document management system and I am told the only documents they want to store are JPEG files, then I am probably being smart to not design my tables around the specificities of images, because when I demo it, they will probably realize they want to store PDF's as well. I just created a heck of a lot more work for myself there.

This has nothing to do with language and everything to do with the reality in software development of rapidly changing business requirements and depressingly unreliable clients.

  • 1
    True, but that follows the rule of representation. If you are representing documents then part of a proper representation is allowing for arbitrary doc types. From my read of the question, they are dealing with transfers, so the model needs to show a transfer attachment. It would be wrong to have transfers and model a resource attachment. OTOH, if they have resources, it is the other way around. Commented Feb 17, 2012 at 15:52
  • 1
    @SpencerRathbun I agree, I was just using Documents as an example that had nothing to do with the OP's Transfers. My point was that if the customer tells me JPEG specifically, then my interpretation of that requirement is Documents because there is a high likleyhood of this requirement becoming more general in the future.
    – maple_shaft
    Commented Feb 17, 2012 at 16:23
  • @maple_shaft I agree that attaching programming languages to either side isn't a good idea, but the observation (not my own by the way) seemed relevant and I put it in there as an example. It definitely isn't my intention to create any stereotypes, I try to make the question objective, which is hard because I have strong opinion on the matter, but I'm trying to figure out if it's a well-founded opinion. To clarify; are you associating the desire to be specific and have clarity about roles, attributes and possible values with the "trollish, stubborn and foolish" stereotype?
    – mark
    Commented Feb 18, 2012 at 17:42
  • @SpencerRathbun there is no resource model, I used the term resource here to indicate that the attachment would not be linked to a specific type of object (we could just drop the resource_ prefix). So in that implementation attachments could be attached to any type of object (documents, transfers, products, whatever). Obviously this makes the resource more flexible, it can provide a broader range of functionality, but this goes at the cost of semantics; the resource becomes vague and abstract. My question is which is preferred?
    – mark
    Commented Feb 18, 2012 at 17:59
  • 1
    @user1214751 My comment about the stereotype was that I heard a very similar argument from a Ruby fanatic once. And as far as the the cons of generalized are considered, the only negative I hear is that it might be a case of YAGNI (You Ain't Gonna Need It). By all means if the general solution takes more time and the schedule is tight then perhaps the specialized approach is better. The only certain thing is that if everybody is fighting about this seemingly inconsequential design detail then that to me seems like the costliest waste of time :)
    – maple_shaft
    Commented Feb 19, 2012 at 4:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.