He was right because there are architecture-astronauts who overdesign things that they don't understand yet.
He was wrong, because the mistake of architecture astronauts is not that they want to solve a template to a lots of problems. Solving a template to a lots of problems can be a huge business. Think of the personal computer. Think of MS Excel. Think of Oracle. It is just very hard to get these things right, because it is very hard to see the market for these generic products in advance. Also generic things are very technology heavy usually, so hard to convince investors. (Maybe I am just defending myself here, because I am also working on a generic application which is about helping businesspeople to access/maintain/query their data intuitively. (Like Excel just with a bit more constraints (with relational db. server backing))).
"He was wrong, because the mistake of architecture astronauts is not that they want to solve a template to a lots of problems."
YES.
This idea has always bothered me: "don't solve a template of a lot of problems, solve one problem."
Isn't that the essence of innovation? To kill lots of birds with one stone?
The problem with "architecture astronauts" is that they over-think their problem, and they spend too much time over-thinking and over-developing before they really understand the problem space. It's a problem of over-engineering and isolation, not wanting to kill more than one bird.
One issue with that is that solving a template of problems really doesn't solve anything specific.
So what you end up with is a framework that solves nothing that requires a bunch of configuration, or unnatural calls to its API(s) to get your one problem solved.
If your 1 problem took, say, 100 "units" of coding; often the framework will take 400 since it's generic. Then you have to code another 50-75 for your one problem.
Sure, the next guy also has only 50-75 to do, but too often these astronauts have no idea of the ROI of the 400, they just assume that "REUSE IS GOOD!" since that's all they've ever been taught. The ROI may never breakeven, much less get profitable.
Also, astronauts VERY often never have to dogfood what they've written, and have no idea if what they've done is actually any good, or usable.
"Before you design for reuse, make sure you've designed it for use." I'm convinced "reuse" has caused more unnecessary code than anyone imagines.
A framework makes a lot of sense for internal applications and large companies. You're often repeating a very similar application over and over (same style, same database, same replace-unwieldy-Excel/Access power user DB problem.)
A framework makes a lot of sense for consulting-ware. Deploying 20 versions of a highly customized application with a lot of reuse. As I see it, this is the use case for Spring. I can't think of another way to easily test such a system.
Frameworks make sense when you need to assemble a team together quickly to solve a problem. You are inheriting a set of best practices that allow a quicker norming phase. Frameworks make sense when you have average and junior programmers as the primary workhorses on a project. (Note: we don't have enough A-listers to solve all of the world's computing problems.)
Frameworks aren't for every problem. That doesn't make them useless.
Both of you (nadam and api) are arguing with a strawman, not what with Joel actually wrote: "they solve something that appears to be the template of a lot of problems"
If something actually is the template to a lot of problems then obviously it's going to be successful.
Maybe I am just defending myself here, because I am also working on a generic application which is about helping businesspeople to access/maintain/query their data intuitively. (Like Excel just with a bit more constraints (with relational db. server backing))
Thanks, I did not know about it. I think this is a still quite undiscovered territory so there is place for multiple companies/products here. (I will follow them to learn from them.)
Thanks. I did not launch yet. I've written 10.000 lines of code already, but even cutting features heavily I can come out with an MVP only at about 18.000-20.000 lines of code approximately.
I try to get good ideas from these kind of applications, but my product's maybe unique strengths are:
- helping agile 'database evolution' by providing schema refactoring, and automatic schema refactoring advice by detecting redundancies.
- automatically creating indexes using query statisitcs.
- presenting a data maintenance GUI based on the relational schema, which is very similar to modern CRUD applications directly developed with the given schema in mind. (for example intelligent automatic generation of form layouts)
- semi-natural query language support. (actually I've extended the SQL Select command's syntax with quite a lot of intuitive and comfortable constructs.)
I think the main problem with the architecture astronauts is that they are trying to nuke a cockroach.
In other words, they are trying to find an overly wide and generic solution while all they have is a specific instance of a problem in a particular implementation they need to design for.
Yes. Solving the generic problem is usually much harder than an actual problem. Only try to solve the generic problem if you really think that there are huge benefits of it, and really know what you do, and you can take huge risks. (Like creating MS Excel instead of creating a special accounting software.)
He was right because there are architecture-astronauts who overdesign things that they don't understand yet.
He was wrong, because the mistake of architecture astronauts is not that they want to solve a template to a lots of problems. Solving a template to a lots of problems can be a huge business. Think of the personal computer. Think of MS Excel. Think of Oracle. It is just very hard to get these things right, because it is very hard to see the market for these generic products in advance. Also generic things are very technology heavy usually, so hard to convince investors. (Maybe I am just defending myself here, because I am also working on a generic application which is about helping businesspeople to access/maintain/query their data intuitively. (Like Excel just with a bit more constraints (with relational db. server backing))).