But the same holds for 100 Yummy Goat Dinners and Classical Oragami Birds.

Abigail

If you follow Fowler's link to Michael Feather's post, you'll find some good material. Feathers writes:

"The next time you are tempted to write and distribute a framework, run a little experiment. Imagine the smallest useful set of classes you can create. Not a framework, just a small seed, a seedwork. Design it so that it is easy to refactor. Code it and then stop. Can you explain it to someone in an hour? Good. Now, can you let it go? Can you really let it go?"

In the discussion that follows, he adds:

Here's an attempt at a definition...

A seedwork is a framework that:
1. Has tests for each class
2. Consists primarily of concrete classes
3. Can be explained in an hour
4. Comes with a promise that it will not be expanded or factored further.

I resonate with this. I get a lot more mileage out of simple, minimal frameworks that I do out of fully elaboborated, bloated, incomprehensible solve-the-world frameworks. These minimal frameworks--call them "seedworks" or call them something else--are somewhere between "examples", and what we usually think of as frameworks.

Ward Cunningham writes something related here:

"For example, if you just blatantly ignore a situation that a future programmer needs to deal with, they will come in to the code and discover that you blatantly ignored the situation. That means they have the freedom to do whatever is required. But if you tried to account for the situation, they will come in and realize it isn't working. They'll see you tried to account for it, so they'll first attempt to understand what you were trying to do. Once they understand what you were trying to do, they can figure out how to change it to do what they know they need to do. They would much rather come in and discover you didn't even think about it. Maybe you did think about it, but you did not program one bit of it."

The point, counter-intuitive to some, is that by keeping a framework simple by not allowing for the future, it can be a lot easier to use and extend now.

I think your Ward Cunningham quote resonates very well with the clasic Worse Is Better story. It adds another explanation how it can happen by showing that the strategy of choosing simpler design is a valid one. The conclusion is that there is a teaching aspect in the programmers work.

A related thought: I've read somewhere about the unexpected aspect of game programming, which is designing the learning experience of the users to introduce them intuitively into the game rules.

I've seen too many cases of "magical programming"^* so that I'm not sure whether I like this meme.

On the other hand, "learning by example" is considered a very valid way of acquiring knowledge and skills by educational psychologists.

To me, it's just another buzzword (but then again, many things are exactly that to me ;-)

Liz

^*Magical Programming
Changing parameters and order of statements in a working program, without any knowledge of the reason for the parameters and the order of statements, to achieve a vaguely described goal. For example: Joe "Magic" Programmer sees a program reading from a file. He decides he wants to make it Internet ready. At the program line where the file is opened, he inserts a URL instead of the filename and expects the program to work.

Circa 1998 I was a contract programmer for the Queensland government, working alongside other contractors who would often regale me with tales of their experiences developing FRAMEWORKS for other programmers to use. I remember how I would inwardly groan every time I heard about these FRAMEWORKS, but at the time I wrote off my groaning as just simple laziness; reluctance to expend the energy required to understand the subtleties of another's handiwork.

Half a decade later my reflection is that it was indeed laziness of a sort, but more and more I feel that it was justified laziness, the sort of laziness that spurs programmers to make the future easier for themselves and others rather than harder.

I'm not saying frameworks can't make life easier, just that they so often fail in this regard. As Ward says:

Now somebody might say, "Why don't we look forward, look at all the work we have to do? Why don't we design a system that makes all work easy from the beginning?" And if you can pull that off, that's great. It's just that, over and over, people try to design systems that make tomorrow's work easy. But when tomorrow comes it turns out they didn't quite understand tomorrow's work, and they actually made it harder.

In fact, many of my private (almost guilty) ruminations over the last few years been related to this theme. In April 2003 I scribbled a few notes and references on what I perceived to be difficulties with encapsulation:

"Encapsulation is the process of hiding all of the details of an object that do not contribute to its essential characteristics." Booch, 1991. Object-Oriented Design With Applications.

"Encapsulation (Information Hiding). A principle, used when developing an overall program structure, that each component of a program should encapsulate or hide a single design decision... The interface to each module is defined in such a way as to reveal as little as possible about its inner workings." Peter Coad and Edward Yourdon, 1991. Object-Oriented Analysis, 2nd ed.

"At the heart of Object Oriented Programming lies the concept of encrapsulation, whereby the programmer gets to hide all the details, especially the shitty ones."EdwardG, 2004

By encouraging the hiding of complexity, encapsulation does not provide for the inevitable imperfection of code that is produced under pressure. If an encapsulated object proves to be inadequate or defective then the situation is much worse for the maintenance programmer than if they had been exposed to the complexity all along. When this situation arises they must come to terms with unfamiliar code in addition to pinpointing and resolving the defect.

Another problem is that changing any moderately complex object risks inadvertently changing the bahaviour of that object, even if only slightly, and so it is often considered necessary to perform full regression testing.

If the development team has previously had bad experiences with "fixes making things worse" then this otherwise reasonable attitude can tend toward paranoia. And when the object is widely used, the cost of regression testing can outweigh the benefit of the proposed change, especially when a fixed deadline looms.

Some things that don't help:

1. Locally created (in house) objects don't always have the same guarantee of quality that (mostly) comes with commercial objects. Arbitrary deadlines generally exert a negative pressure on quality.

2. Feature creep. The initially simple and useful object is continually modified to add "just one more small but important feature" and with each new feature the object increases in complexity.

There's more to be said, but this is too tangential already.

I think a good framework ist a mirror for the hackers philosophy.

That means, if the reader of the document must be better or absolutly involved in the special part of the new modul it's a wasted time to start with it

So a easy to start example is recomented

3 days with about 2 or 3 h, to find out how CGI::Application + CGI::Application::TT and CGI::Application::Session together as classimplementation like # In MySuperclass.pm: works
CGI::Application::Session is not working yet in my code (no cookies are send)

a first workaround by using CGI::session (cookies = ok)

is like wasted time
WHY

easy to answer - i'm still Beginner and i'll start to code more OO as in the past.

different codingstyles and so on makes easy things very difficult to understand

so the workarounds begin and after all a total rewrite may be the best way

Be well.