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

Oh my God, he understands!!!!!!!

If I had to quote every paragraph of Paul Graham's latest release that I agree with I'd have to just transcript the whole thing here.

¿maybe?

On a political note, shame on The guerrillas responsible for these. How can they say it was the military's fault. They look like that nutcase that says "they made me do it" in front of the still warm body of his victim. A weblogish minute of silence for the victims, and a cry of war for the slaughterers.

I've been rather busy these days, between work, extra work, family matters and everything I hadn't had the time to review the blogs in quite a while. In the meantime, a holy war has formed between Some and then some. With the outcome of.... increased functionality for us, lazy users.

On my continuing meetings with that abstractuos entity called the client, today I went to a major bank like institution, to talk shop. Up until now the jobs I undertook where ones where I "had the ball", to say it in soccer terms. This means I was the dummy selecting the platform, developing the technology, choosing the framework, etc etc. With this one It has not been like that. It means a lot of requierements come from high above. What amazes me the most is the apparent lack of care, on behalf of the client, for the financial side of the thing. Back in small-website-made-from-scratch days the client was a tough sell, you had to take away every penny from him, and he would expect the delivered program to do everything from rocket science to calculating the net worth of the whole company with a single keystroke. Here it was different, they knew the thing was hard and were not concerned with the tab. They only wanted to know the size of the check they had to sign. The money stopped mattering, and it was the flux of information that became important, knowing what to expect and when to expect it, and having someone to blame if something happened (could this be what "software business" is about?).