The Cathedral vs. the Bazaar

It seems people bring this over and over: Why don't small teams of programmers in a garage replace them huge teams we see today?

It seems that the explanation is that their respective products are in a different category.

But I doubt it.

Most big projects are just massive copy and paste and they could be replaced with the right prototypes and building abstraction layers (with the right abstractions of course), but it seems managers prefer to fail: They prefer the predictable and long development cycle, because when you fail it is already too late, massive amounts of money have gone through the drain and therefore managers are in a better position (they have already been paid for wasting time and money) to negotiate even better pay.

When people are confronted with 2 alternatives: one that can produce better results, but that if fails means you have no scapegoat, and another that will eventually fail but you have an scapegoat, people prefer the one that will fail, but has an scapegoat. The reason is that people get hired to avoid uncertainity, and I'm sure people in latin america prefer this situation all the time.

There are many examples and you probably have been in many: it is very common for projects to avoid proptotypes, because prototypes can show which design decisions work and which can't probably work. If they work or not can be explained with developers who lack the required knowledge or bad design decisions. It doesn't really matter, since design decisions must be the ones that developers can implement.

But developers tend to avoid writing prototypes because they could be accused of not knowing how to build this little examples, and designers do not like this for the same reason: the code can be corect, but the design can be shown not to do as expected, therefore, people prefer the non accountibility of delivering a mess.

And the big problem of a code that is a big ball of mud is that no one can fix it because no one can understand it.

The different category if Wikis

It is amazing how people think that people in a garage can't produce the complications coming out of their little brains, but they can build a computer in a garage.

I mean, come on, a computer is a lot more complex than the mumblings fo a business analyst or a user. Usually the businesses are plain simple and hide behind a courtain of poorly defined words. There is usually no more than that. A little script in Excel can usually replace the biggest experts.

When it comes to Wikis, I already mentioned that they are great and usually people don't use them for the worng reasons. I think the world would be a lot better if the Wiki was invented just a few minutes before the Web. The Web language is just so complex and lacking even the minimal amount of think ahead.

Almost everything in the web is thought for today business and if you need something else, you need to extend the web protocol or the web language and you end up with incompatible browsers. This rant I heard it first from Alan Kay, one of the inventors of Smalltalk, and he proposed a solution, a little language that would explain itself to the browser.

So you could easily change HTML and the new HTML tags would explain themselves to the browsers, I can already imagine this because tag libraries work like that, although the browser doesn't have a clue about them.

Most systems can be implemented as a Wiki. As I already mentiones, the access restrictions of the Wiki can be introduced using AOP or dynamic proxies.