MindRetrieve Blog

MindRetrieve - an open source desktop search tool for your personal web

Wednesday, May 31, 2006

From Simple to Complex - A Reflection on Framework Design

For a while I have used the Jakarta Struts framework in web development. I was quite overwhelmed by the number of configuration files and entries I have to wade through to get anything done. All these configurations are put in for a reason. The offer users a degree for flexibility. These are knobs you can tune to set the system up. With these knobs you no longer need to open the box and rewire things when you want to fine tunes things later.

Alas this makes a steep learning curve. It takes a lot of work to get just some simple thing done. Also when things go wrong, it is very hard to track it down. Unhappy programmers are the result.

It just occur to me that there is a pattern in this kind of issues in framework design. A lot of simple things adds up. When looked at a system scope, it results in something very complicated. The options of struts all serve a purpose and is not hard to understand by itself. But because you need to use all of them in your application, the overall pictures is complicated.

I will use foreign language learning as an example. You learned and memorized many grammars rules: singular v.s. plural, subject v.s. object and so on. You went through the drilling exercises quiet well. Then the challenge came when you need to read or write a full sentence. Your tongue tied, mind gone blank. Why? Because a real life sentence is free formatted. Out of the many grammar rules you've learned perhaps two or three is relevant in the sentence in front of you. The hard part is you don't know which two or three should apply. Although you understand each rule individually, together they become a challenge.

Some lessons I have learned as a user and designer of framework are:

1. Look at things at system level, not just individual feature level.

2. Use common pattern that user have already learned. Clever one-off trick may be an advantage on individual level, but it complicates the system as a whole.

3. Design a framework can do simple work without much training. User can learn gradually when they need to do something complex.

4. Spend time to learn the detail of the system. Like the foreign language analog, sometimes there is no shortcut but to learn really hard. If you are a user who stuck with a complex system you have to use this applies to you. For framework designer, better stuck with point 3 than assume your users' dedication.

5. Finally, provide a tool to manage complexity. If an action have to involve 2 beans, 3 templates, and 5 validation rules, make a tool to help user to track them down. Surprising much of my time in software development is spent simply in tracking these things down manually.

Rudy on Rail's convention over configuration philosophy is a good example. It uses a simple rule consistently (naming notation as the main logic). It can get simple thing to work easily and complex thing possible.


  • At 1:28 PM, Blogger James Gray said…

    I think these are great ideas.

    I have a few to add:

    1. When the user creates a new 'project' or new object of any sort, create a working template "hello world" program. Thus a new user can see all of the parts that a working program needs. This also cuts down the mundane details for more advanced users. At every stage of development the user can have a testable system. [Idea from ruby on rails]

    2. Give a user a group of specialized components with matching APIs and allow the user to decide which ones are useful to her application. She can chose the simplest parts when they fill what she needs and use more complicated ones when additional flexibility is needed. [Idea based on my thinking about WSGI protocol]

    3. The framework can be designed to encourage coding that is more flexible, and allows bugs to be caught earlier and localized more quickly. [Idea based on various sources]

    4. My experience is that having 'callbacks' in a library tends to make coding/debugging more default because it forces the user to learn/know more details about how the system works then otherwise would be needed.

    5. Framework should work in conjunction with existing tools. Like unit testing, HTML/XML editors and such.

    6. Have good, complete documentation: tutorial & reference. :)

  • At 12:12 PM, Anonymous FreeFlashClocks said…

    This comment has been removed by a blog administrator.


Post a Comment

<< Home