This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.

×

This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.

×

QCon - Thoughts on the Generic vs Specific Trade-off

Stefan Tilkov gave a very interesting talk on the problem of when to choose a specific or a generic solution. While there were no answers provided, after all it's one of those things where there can be no general answer, it was definitely an entertaining and thought-provoking talk.

He started off be describing what he saw as the typical development of an architect. One starts out, fresh from university all keen and eager to build some exciting and cool software. This is the "Enthusiastic Developer" stage. Unfortunately it turns out that what customers want is typically boring, boring, boring - "create a system that allows us to maintain Customers"; "create a system that allows us to maintain Products", and so on. This leads to the "Disillusioned Developer", repeating similar tasks day in and day out. Then, having seen that they are doing something that looks the similar each time, the newly minted architect decides to build a generic solution, a "maintain generic things" engine. Then we can spend just a little time (oh it will only take us a few months to get the framework finished) and then there is only a small amount of specific configuration required, say 20% of the over all total effort. This is the "Enthusiastic Architect".

So they spend 80% of the time building this wonderful generic solution and then then remaining 320% of the project on the rest of it. The problem being that customer's don't really want generic solutions. The form that they want to use to maintain their customers has to behave differently from the one used for products (otherwise they'd use Excel right), it's all those little exceptions that one has to introduce to work around the generic solution, or to extend the generic solution into an all signing and dancing framework that takes the time. We've all been there, well at least all of us who are honest and will admit it. This leads to the "Disillusioned Architect".

He gave a fun little quote: "Some programmers when faced with a problem turn to a generic solution... Now they have two problems."

Finally, hopefully, we get to the "Wise Architect", now the answer to the question, what should we build for this problem, is now "well it depends".

It was an amusing introduction to the topic and certainly set the scene very well.

Stefan, then went on to describe some examples of generic and specific solutions. For example, one could represent data as XML in a specific schema or as XHTML; one could provide access to data via specific SOAP based web service or as an Atom feed. Both the specific and the general have their advantages and disadvantages.

And of course the answer to which to choose in a given scenario is "it depends". It depends on a number of factors. Stefan outlined some criteria that might be helpful.

A general solution might be appropriate if there is a "useful" ecosystem, for example XML has lots of useful tools for querying and manipulation, so a general solution using XML documents for data transfer may well be appropriate if you want to be able to make use of this ecosystem of existing tools.

If the generic solution is an "obvious match" then it makes sense to use it - though beware of "obvious" matches, is it really that obvious? A content management system is a generic solution and might well be the obvious match for building a content strong web site, but do you really need the flexibility of the content management system or would it be easier to build a Ruby on Rails solutions if the content you're managing is straight-forward.

If you have existing skills in a generic technology, then it might make sense to use that rather than look at something new.

And of course, if you're in a static environment, where a particular tool is pervasive already, should you fight to change it, even if a specific solution might be a better fit.

Conversely, a specific solution could be right if you're looking at a particular niche need, if there are no generic solutions already and it's unlikely that you'll ever want to reuse anything in the future then the time and effort spent on a generic solution could be a waste.

Similarly if you have "unique problem" then a specific solution makes sense, but as with "obvious matches" beware of "unique problems". Is it really that unique?

Performance may be an issue, that might be more important to you and using a generic solution. A binary data interchange format might be better than an verbose general XML one.

All in all this was a very interesting talk. Stefan had a very engaging presentation style - go see him if you get the chance - and he made some very interesting and thought provoking points. Definitely worth the hour.