Don’t Put the Cart Before the Horse

April 2nd I made this undiplomatic statement (funny how Twitter practically encourages being provocative):

#ZF 2.0 is a great example of second-system syndrome.

Matthew Weier O’Phinney and I have a good working relationship. I think his work on the Zend Framework project has been amazing, both from a technology perspective and a marketing perspective. 
Matthew and Bill
So when Matthew asked me to clarify my Tweet, I was happy to reply, in the spirit of constructive criticism. These thoughts apply to many projects–not just ZF–so I thought they would be of general interest. Here’s the content of my reply:

When I’ve reviewed project proposals or business plans, one thing I often advise people is that you can’t describe the value of a project in terms of how you implemented it. Users don’t want to hear about how you used XML, or dependency injection, or unit tests, or agile methodology, or whatever. They want to hear what they can do with this product.

After reading the roadmap for ZF 2.0, I observed that a great majority of the planned changes are refactoring and internal architectural changes. These are worthwhile things to do, but the roadmap says very little about the feature set, or the value to users.

What I’m saying is that implementation does not drive requirements. That’s putting the cart before the horse.

I admit that for a developer framework, this line is more blurry than in other products. Your users do care about the architecture more than they would for a traditional application. But that still doesn’t account for the emphasis on implementation changes in the roadmap, and the lack of specific feature objectives.

For instance, some goals for the controller are described in a list of four bullet items: lightweight, flexible, easy to extend, and easy to create and use custom implementations (which sounds close to easy to extend). Then it jumps right into implementation plans.

So how flexible does it need to be, and in what usage scenarios? What does lightweight mean? How will you know when it’s lightweight? Are there benchmark goals you’re hoping to meet?

Another example is namespacing. Yes, using namespaces allows you to use shorter class names. Is that the bottleneck for users of ZF 1.x? Do you need to create a namespace for every single level of the ZF tree to solve this? Would that be the best solution to the difficulties of using ZF 1.x?

The point is that the way to decide on a given implementation is to evaluate it against a set of requirements. You haven’t defined the requirements, or else you’ve defined the requirements in terms of a desired implementation.

My view is that requirements and implementation are decoupled; a specific implementation should never be treated as one of the requirements, only a means of satisfying the requirements.

Bill Karwin



, , ,




8 responses to “Don’t Put the Cart Before the Horse”

  1. Bill Karwin Avatar

    Matthew is an awesome, hard-working guy with a genuine passion for making his project the best he can.

    He commented to me that my feedback was valuable, and he's working on his ZF 2.0 roadmap to take these thoughts into account.

    The ZF 2.0 planning is still in its early stages so I'm glad if my feedback has been timely.

    I'll be interested to see what Matthew and the ZF community come up with over the coming months. Don't rush on my account, folks!

  2. rvdavid Avatar

    "My view is that requirements and implementation are decoupled; a specific implementation should never be treated as one of the requirements, only a means of satisfying the requirements."

    This makes lots of sense and I'll be taking this on board as I have noticed that some of my most recent proposals are slowly becoming way too rich in implementation details while not fully describing how the solutions we propose meet the projects requirements along with the features and benefits of the solution.

    Thanks for posting.

  3. Andy Avatar

    A lot of the refactoring and re-architecturing is around making ZF faster — which is definitely a feature it's users are looking for. ZF has always been the turtle of web frameworks. Yes, you can make it fast with a whole bunch of tricks, but it's definitely not fast out of the box. Speed has never been an emphasis and I'm glad to see a huge effort of ZF 2.0 go towards that.

    I tend to agree with you on the namespacing issue. Granted, I have not had the opportunity yet to play with PHP 5.3 namespaces, and they do sound pretty cool, but today as things stand this is not a huge blocker for me (especially when you have an IDE that can do basic class auto completing).

    Personally I'd love to see them pair down the library into a deeper core set and strip all the libraries that I'll never use (the many Service variety libraries where you'll almost never use all of them in a single app) into a secondary extra set of library. But I guess that philosophy decision has already been made.

    I'd love to see Zend tackle a real model implementation as well. Doctrine does some pretty cool stuff and demonstrates what is possible. I'd love to see either more formal adoption of Doctrine or a well thought out model solution.

  4. Bill Karwin Avatar

    @Andy: Great, if performance improvement is the aim of the ZF 2.0 refactoring, then they should say so in the roadmap.

    For example, the requirements should include the scenarios they want to speed up. Also, give specific target numbers for how much they want to speed it up. And if there is any functionality they would be willing to give up in order to make the code simpler and faster, that would be good to mention too.

    Performance is a perfectly good goal. It just needs to be in writing, and be SMART:

  5. Chris Avatar

    mmm am not too familliar with ZF development.. but aren't most features still being programmed by whoever wants to do it… meaning that it's very hard to define the feature set other then the basic framework kit (mvc, helpers, modules, etc)

  6. Bill Karwin Avatar

    @Chris: Hi thanks for the comment. Yes, ZF encourages community involvement to propose and implement new features, but Zend does have a few full-time developers on the project too.

    So they can prioritize some set of components that they want to develop in-house.

    Also they can set quality standards for community contributions, so if they have a performance goal for the framework, they can use that as a criterion for contributed components.

    In any case, the advice that project requirements should be specific and achievable applies to many projects. Zend Framework was just an example.

  7. esrh Avatar

    Really? IMHO – From "marketing perspective" ZF is hugely lacking behind codeigniter for example.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.