Dr. Blip's PC-Doctor Blog
#1 - Andy Koch 2008-05-05 13:35 -
Nice post Fred, reading through it my mind keeps flashing to thoughts of Merb. Merb is a Rails spin-off framework that was created with some very specific goals - as is your framework.
I've been keeping my eye on Merb development over that past year. Reading blog's by it's creator has been an interesting view of how frameworks are born, develop and grow with respect to the original goal and the guiding principle of the developers.
The Merb team believes that "no code is faster than no code" - thus only code what is needed and nothing more. They also believe in clarity over cleverness - so Perl-isms are right out. I think this guideline goes a long way to keeping the framework developers, present and future, relatively happy. This also results in Merb not having any tools built-in. In fact Merb is split into Merb-core and Merb-more - where merb-core is all you really need and merb-more has all the helper tools if you want them. This seems like a good balance.
I think a framework should hide complexity from the end-user. Take Rails ActiveRecord for example, it has thousands of lines of code - but it's beautiful to work within a Rails app since the coding is so simple (usually). When faced with complexity I would always choose to bury it in the framework and make the end-users blissfully ignorant. But also provide access to the complexity - as some end-users will end up in situations where they need to get down to the nitty-gritty, they shouldn't have to fight the framework to get it done.
One thing I didn't see though, you are Unit testing your framework aren't you? Well, maybe if this is never going to be an OSS thing it won't matter so much - but it should help to make future developers happy.
#1.1 - fred.bertsch 2008-05-05 14:10 -
Glad you liked it!
Yes, putting complexity in the framework scales extremely well. If a framework gets used to develop N applets, then a naive analysis would say that you can make things N times more complex as long as it avoids making the user do anything.
It's a lot better than that, though. N gets bigger as it becomes easier to use the framework. ActiveRecord is a great example. It's complex inside and simple on the outside. If they had reduced the complexity of the implementation at the cost of making the users' code uglier, it wouldn't be nearly as popular.
It's difficult to make that claim before you have those users, though. Currently, I've got one user Louis in QA who is comfortable modifying existing applets. How do I sell additional complexity to management? My current philosophy is to mostly ignore management, but that makes the cost of failure extremely high.
Our last release was an interesting test, actually. I just barely managed to get all the features I needed in the framework before the release. I had almost no time to write the actual applets.
Fortunately, the framework was simple enough that I could teach Stephen (and Louis in QA) enough to write and modify the applets. In fact, Stephen ended up writing a bunch of extra applets that weren't requested by our client.
So far, I completely agree with you, Andy.
#2 - Andy Koch 2008-05-05 14:18 -
I think the additional complexity will sell itself. If the framework is popular with customers they will no doubt start to push the limits of it's capability. As that occurrs they'll start pushing for more features to ease their work.
No one can put pressure on "the Man" quite like customers, especially the paying kind.
Have you got a name for this framework?
I vote for "BertschNET on Railstype Development", or you could simply call it "BoRD"
#3 - fred.bertsch 2008-05-05 14:29 -
Isn't that cool? I managed to write for waaaay too long without ever saying what the framework does or even what it's called?
Believe it or not, I actually cut stuff out of my posts before publishing them!