3 ms·

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

15 points by bdfh42 18y ago

gaius 18y ago
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.
- mrtron 18y ago
  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.
  - cstejerean 18y ago
    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.
DanielBMarkham 18y ago
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.
robinhoode 18y ago
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.
- swombat 18y ago
  New features every week doesn't mean the features are badly built.
sunkencity 18y ago
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. :)
aggieben 18y ago
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.
edw519 18y ago
There are so many assumptions that go into the framework that some of them are bound to be wrong. For example...
- run4yourlives 18y ago
  How about the fact that you think you need a framework at all, for starters. :-) Yes, that's a little facetious.
- baha_man 18y ago
  '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.

15 points by bdfh42 18y ago

gaius 18y ago

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.

mrtron 18y ago
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.
- cstejerean 18y ago
  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.

DanielBMarkham 18y ago

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.

robinhoode 18y ago

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.

swombat 18y ago
New features every week doesn't mean the features are badly built.

sunkencity 18y ago

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. :)

aggieben 18y ago

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.

edw519 18y ago

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

run4yourlives 18y ago
How about the fact that you think you need a framework at all, for starters. :-) Yes, that's a little facetious.
baha_man 18y ago
'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.