I'll get to your application in a minute - First, we need to build the framework | Hacker News Reader

I'll get to your application in a minute - First, we need to build the framework

jeffreypalermo.com

15 pointsbdfh4211 comments

I don't think that framework building is necessarily a bad thing - it's no conceptually different from bottom-up programming. The problem occurs when no top-down programming occurs at the same time, so there are no actually working features until the framework/DSL is completed. This is mainly about a PM who didn't keep a grip on what the team were doing - just another reason that non-technical PMs are a bad idea.

I think this thinking is what got them into a mess. Sure it sounds like a great idea to create a framework, but for a one-off project it just doesn't make sense.

I think you would be much better off in that scenario trying to build great components that are well defined and contained. This would enable you to re-use them in future projects, or when you build your framework later at some point.

Building great components that are well defined and contained is not very different from building a great framework, and both approaches can get you in trouble.

Interesting, I've myself built too many frameworks.

There are good frameworks available for ruby and python. For java and php the frameworks are too big and cumbersome so people build their own 'frankenstacks' to get away from the code bloat that comes from programming with a c style static language (talking about java here) for a generic problem, and focusing the framework for the current problem at hand. I'm not a good framework programmer so I'm perfectly happy using rails and trying to forget all crappy PHP based frameworks I've built myself in the past. :)

Right on. I'm working on a contract like that right now, and our "lead developer", so to speak, is doing exactly this (i.e., do BDUF, write the framework first, and I'll get to your application when I get to it). The money quote that really stood out to me:

  Frameworks are better harvested from several applications 
  that ended up using similar patterns.

New features every week? At that rate, you're bound to make yourself quite a mess. With almost every project I've worked on, the complexity becomes so unbearable, I end up refactoring everything into half of a framework. I would dare say that you'd need a lot more than that to get flexibility from a language like C#, which this particular blogger seems to be supporting.

New features every week doesn't mean the features are badly built.

I think Jeff's off-base here -- but he makes good points.

The problem is that all programs _should_ involve some generalizations and framework-type activities. It's just that it's never the focus of the actual project. There are all kinds of interesting and complex situations to consider when considering how much of a framework to build and why, but he never gets into those nuances, instead opting out with the easy "customers pay us for software, not for frameworks"

Well gee -- that's pretty self-obvious. What's less self-obvious is how the right amount of framework activity can super-charge the entire bag of software features.

I felt like I got a slogan, not real advice.

There are so many assumptions that go into the framework that some of them are bound to be wrong.

For example...

How about the fact that you think you need a framework at all, for starters. :-) Yes, that's a little facetious.

'There are so many assumptions that go into the framework that some of them are bound to be wrong...'

...but at least those assumptions will be documented in code.

Reply on news.ycombinator.com