5 ms·

Framework First, Product Later

60 points by tomjakubowski 14y ago

vineet 14y ago
A few years ago, someone pointed out to me that Coding is actually a design task. That when you code the answers of how to code something are never obvious. 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.
- RyanZAG 14y ago
  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.
- droithomme 14y ago
  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_main.html 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.
jsavimbi 14y ago
"we went in search of applications to build" Talk about putting the cart before the horse. Having worked for spinoffs, spunouts, "we're from MIT" and a host of others throughout my career, I can attest that those with the greater chance of success are those who identify a need in the marketplace and focus all of their efforts, business, design and engineering, on solving a problem that people are ready to buy into. Building a framework for the purpose of later trying to find ROI on it is an expensive and often futile endeavor.
RTigger 14y ago
I blogged about the "moral" of this story a few months ago - http://rtigger.com/blog/2012/07/06/architecture-last/ http://rtigger.com/blog/2012/07/06/architecture-last/ TL;DR - Frameworks should emerge from use cases, not the other way around.
hartator 14y ago
"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? :)
- nicholassmith 14y ago
  RoR was extracted from Basecamp. Sorry to be that guy.
  - hartator 14y ago
    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 :)
jiggy2011 14y ago
What about frameworks like MVC .Net and Spring framework? What codebases were these extracted from?
- pcote 14y ago
  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.
  - lloeki 14y ago
    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.
blackhole 14y ago
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.
nicholassmith 14y ago
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.
- camus 14y ago
  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.
No1 14y ago
"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.

60 points by tomjakubowski 14y ago

A few years ago, someone pointed out to me that Coding is actually a design task. That when you code the answers of how to code something are never obvious. 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.

RyanZAG 14y ago
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.
droithomme 14y ago
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_main.html 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.

jsavimbi 14y ago

"we went in search of applications to build" Talk about putting the cart before the horse. Having worked for spinoffs, spunouts, "we're from MIT" and a host of others throughout my career, I can attest that those with the greater chance of success are those who identify a need in the marketplace and focus all of their efforts, business, design and engineering, on solving a problem that people are ready to buy into. Building a framework for the purpose of later trying to find ROI on it is an expensive and often futile endeavor.

RTigger 14y ago

I blogged about the "moral" of this story a few months ago - http://rtigger.com/blog/2012/07/06/architecture-last/ http://rtigger.com/blog/2012/07/06/architecture-last/ TL;DR - Frameworks should emerge from use cases, not the other way around.

hartator 14y ago

"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? :)

nicholassmith 14y ago
RoR was extracted from Basecamp. Sorry to be that guy.
- hartator 14y ago
  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 :)

jiggy2011 14y ago

What about frameworks like MVC .Net and Spring framework? What codebases were these extracted from?

pcote 14y ago
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.
- lloeki 14y ago
  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.

blackhole 14y ago

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.

nicholassmith 14y ago

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.

camus 14y ago
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.

No1 14y ago

"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.