Making software and talking about making software

I know everybody is going to say they knew it. I have to confess I was rather naive. I used to think that the process of building software was about building software.

I used to thing that, in good old fashioned hackerish style, good code should speak for itself, or, to put it in a broader canvas, a good work should need no other help than that of it's contents to be known. Turns out that twisted mixture of influences, known as reality, is not like that. If no other influences existed over the software process, probably it would be about making software, and not much else, just like painting should be about painting. However, when making software one has to think about the software being useful for somebody (which is a good thing) and, in a lot of cases, profitable (as in built on time and under budget), which is not a good thing from the purely theoretical point of view. To add to this already messy melting pot of interests, it is probable that software has to live with existing infraestructure (existing machines, existing software or existing user habits).

As a result of this too much time is spent on talking, talking to other developers, talking to software users, talking to vendors, talking to bosses, talking about the best way of doing things. When compiling a 52 line COBOL program meant punching a whole deck of cards and running it through a machine that only allowed two programs a day per individual, it was right to talk a lot about the software, to actually build it in paper before really building it. But right now, when the length of the cycle has shortened so much.... Is it still necessary to lay out all of the thing that are to be done before actually doing it? Is it even possible? Is it possible to think in advance about all the possible things that might be needed in a devolpment process, and to do so even before the development starts? Furthermore, is it even wise to try to do this?

I think not. I thing that we should use the fact that 90% of a program's functionality is built in 10% of the time (or 80-20, or whatever, numbers can be found to back up any division of those two figures) to our advantage, to let the code talk, because, what's better to demonstrate how a piece of software will work than the piece of software herself?

Talking about talking, today Colibri had 30 messages of people ranting, I don't even know about what. discussing if discussing was a good thing to do. That's our problem. If that time that was spent ranting or back ranting, was spent coding, or translating, or thinking, we would advance faster.

Software building doesn't work by consensus. A lot of very succesfull projects (GNU, Linux, Matanza, etc) work by dictatorship. Everybody can contribute, but there is a reduced core of technically skilled people that has the absolute truth on what goes in and what doesn't. You don't like it, you can fork it.

The amount of caffeine inside my veins will have to be rised as I head into another talk about talking about making software. Yee-hay