Keith Devens .com

What made you decide to pan your CMS in the first place. I remember how much time you spent on it, plus the amount of time you spent plugging it ... so you must have had a startling revelation.

I started to go into some of the things in the beginning of this post. Probably the main thing that set me off was this post about keeping things simple, even if that means having it be boring. It was a good wake up call, as I realized that a lot of what he said applied directly to me. That was very helpful in slapping me back into shape.

I realized that I really kept to the mantra of KISS when writing libraries or code for other people to use, but for myself I ignored my own good sense. Partly, I wanted to try to build a big web application framework (like Struts) and see where it led me. I wanted to at least attempt to figure out how I'd build an ideal system, and take that to its logical conclusion. I then realized that there is no ideal system, and every system has to be driven by "business needs" (hence the reference to YAGNI in that first post). Though, I do think I came up with some good ideas and learned things along the way.

I also realized that much of what I liked about my CMS could be recast as libraries and didn't need to be part of a big framework. Ian Bicking was a help here (I linked to that in that first post as well). Finally, I did wind up using much of what I learned while making my CMS about the right way to structure these things, and I'm applying that to my much simpler code now. I'm actually winding up with code that I like (even in PHP!), and which I can actually find things in.

Back when I tried to find that post by Ian Bicking, I wasn't sure exactly what the post was that I was looking for. I'm pretty sure I found the main one, but I think this one also may have had an influence:

This is some of what I was referring to when I said that Smalltalk programming styles led to too many frameworks and not enough libraries -- a framework requires you to take on a certain metaphor of execution, to adapt your thought process to the framework instead of adapting the program to your thoughts. Frameworks can be worth it, but they always exact a significant cost.