Framework First, Product Later(programmingisterrible.com)
programmingisterrible.com
Framework First, Product Later
http://programmingisterrible.com/post/41268612135/framework-first-product-later
15 comments
It's actually more than that.
Software design/architecture is always for new never-before tested or built products. Even building a new mobile app is generally building something never before seen.
When you compare this to an architect designing a bridge, there are thousands of identical water-spans that have had bridges built on them. Most of it is just following best practice.
If you want to try and compare architecture for a building to architecture for software, the closest you can get is to designing a building on mars. Sure, you've designed walls before and water proof buildings for ocean use, but you've never built on Mars before. Every single time, for every single novel software project, you're designing something new. This is why software is hard, and why trying to manage or build software as if it were a bridge nearly always ends in tears.
Software design/architecture is always for new never-before tested or built products. Even building a new mobile app is generally building something never before seen.
When you compare this to an architect designing a bridge, there are thousands of identical water-spans that have had bridges built on them. Most of it is just following best practice.
If you want to try and compare architecture for a building to architecture for software, the closest you can get is to designing a building on mars. Sure, you've designed walls before and water proof buildings for ocean use, but you've never built on Mars before. Every single time, for every single novel software project, you're designing something new. This is why software is hard, and why trying to manage or build software as if it were a bridge nearly always ends in tears.
I agree with you. The Programming is Design position was elucidated very nicely by Jack Reeves in his paper "What Is Software Design?" some time ago.
http://www.developerdotstar.com/mag/articles/reeves_design_m...
Not realizing that programming is a design task has led to a lot of problems in many projects.
http://www.developerdotstar.com/mag/articles/reeves_design_m...
Not realizing that programming is a design task has led to a lot of problems in many projects.
"However the patent covered migration, so no matter what, migration was the solution. We wrote the framework around the patent..."
They realized early on that there was a better way to do things, but stayed the course because they had to make something that used the patent. I don't think the framework ever had a chance from the beginning.
They realized early on that there was a better way to do things, but stayed the course because they had to make something that used the patent. I don't think the framework ever had a chance from the beginning.
I blogged about the "moral" of this story a few months ago - http://rtigger.com/blog/2012/07/06/architecture-last/
TL;DR - Frameworks should emerge from use cases, not the other way around.
TL;DR - Frameworks should emerge from use cases, not the other way around.
I was working for a company a few years ago who started building a web app in PHP. We had a new PHP developer who was very confident, who had what he claimed was a fantastic PHP MVC framework he'd written in his spare time. You can guess where this is going, but because he'd just written it as a framework instead of building it around a product and then extracting it out, the majority of the time was spent shoehorning the product to fit the framework.
I'm sure there's frameworks that exist that haven't been extracted from a product that do a perfectly fine job, but I've found that when they fall into the extracted category they've already had a round of battle hardening done, which makes life somewhat easier.
I'm sure there's frameworks that exist that haven't been extracted from a product that do a perfectly fine job, but I've found that when they fall into the extracted category they've already had a round of battle hardening done, which makes life somewhat easier.
a framework by definition is to help bootstrap whatever product you want to build.If a framework gets in your way , ditch it.
Anyway i think , thanks to composer we are way passed using a single monolitic framework. I often use symfony libs , but never used the kernel. That's what make the lib very good.
Anyway i think , thanks to composer we are way passed using a single monolitic framework. I often use symfony libs , but never used the kernel. That's what make the lib very good.
This inevitable schism between features that are nice and features that you need are why I am sitting on multiple frameworks without releasing them, because I refuse to release a framework I haven't built something with. I've had to rewrite those frameworks multiple times after realizing how broken they were in a real-world scenario.
What about frameworks like MVC .Net and Spring framework?
What codebases were these extracted from?
What codebases were these extracted from?
Spring was born from a book on application design written by an expert on the subject. MVC .Net was probably the result of the sort of R & D that companies like Microsoft can afford to do and do well.
IIRC ASP.Net MVC had folks from Castle Project's (of Dynamic Proxy fame, extensively used by NHibernate) ActiveRecord+MonoRail framework working on it, which was itself (as it can be guessed) heavily inspired by Ruby on Rails.
"If you encounter a framework that wasn’t extracted from a product, run away screaming, no matter how extensible it claims to be."
You mean Ruby on Rails? :)
You mean Ruby on Rails? :)
RoR was extracted from Basecamp.
Sorry to be that guy.
Sorry to be that guy.
Sure, was just kidding around.
Rails in another do feel sometimes, a bit too academic, like thinking more about a software design stand point than a tied to reality issues.
Disclaimer: Big Rails User :)
Rails in another do feel sometimes, a bit too academic, like thinking more about a software design stand point than a tied to reality issues.
Disclaimer: Big Rails User :)
In contrast, someone putting the bricks down to build a house has a much more defined task. The architects for real world houses were really the only ones doing design and that for 99% of them, they were good at it only when they were essentially designing a house that they had seen most of the parts already built in the past.
While design is not very easy, it is very hard (and way too abstract) to do design^2. Humans are just not very good at it. And that we should be very careful being a software designer or as the OP suggests building a framework without a concrete product built first.
Note: When I mean software designer above, I mean someone trying to spend a large percentage of their development specing out all the details that the coders (i.e. the designers of the software world) should be working on. I am not referring to Graphic Design.