Re: Re: Re: Re: regarding the On Colaboration reblog on

I agree, that exploratory coding can be good!

Its interesting that coders and engineers, in general, are materialistic, with this idea of defining an exploratory process as 'hacking'. That is the accepted thinking, that unplanned coding is dangerous, unprofessional, and leads to 'bad design'. I disagree, in terms of coding as an artist. If you are making software to run businesses, then yes I guess its hacking. For art, then NO. That is akin to saying that someone who is making a painting with zero preparation or structure, is hacking the painting. They are just painting, not hacking. Some people are good at that sort of process, others have the painting all worked out before touching the canvas. Either way works and can lead to 'good painting'. Same with code, some are keen with preparation and abstract design, other just want to code and let the coding process bring them somewhere. But the materialistic software world would call that a 'hack'. To me, its not. That word doesn't make any sense here. Why can't the mistakes, bugs, weird design decisions, unplanned diasasters that are barely corrected, the human neurosis and error be part of the beauty?

I understand where you're coming from, Steve, but this statement sort
of reveals quite a bit of misunderstanding of both the culture and
attitude behind software engineering as it is actually practiced.
This is sort of a typical example of stereotypes that arise from a
lack of understanding across the divide between engineers and
artists …

Software engineers are simply not "in general, materialistic" — I
can see what you're trying to say here, but it doesn't correspond to
anything actually real in the culture of programmers. For example,
you talk about exploratory programming as though it were called
"hacking" — but hacking, as a word, in not necessarily perjorative
(a "hack" is sometimes considered perjorative, but "hacking" is not).

The word "materialistic" as you seem to be using it implies a sort of
unimagintive plodding along, building things like big grey concrete
boxes, or something like that. This really doesn't correspond at all
to the actual culture of software engineers, who employ all sorts of
different strategies ranging from the highly planned to the highly
exploratory.

There is a style of programming, for example, called "Extreme
Programming" which is precisely designed to involve very quick
turnout, building features that work quickly, and so forth. This is
part of a very popular trend in programming called "Agile" methodology.

In addition, as I've said before, the whole point of architecture for
software is precisely to ALLOW for change. The problem with just
building software with no thought about its structure is that,
typically, you end up with something that becomes very difficult to
change. It takes longer to build structures that allow for change,
but if you do, then the software itself becomes much more flexible,
allowing for much greater exploration later on. If you dive in and
code without thinking about structure, you'll get something to happen
quickly, but find yourself slowing down a great deal later on.

"Agile" methods are designed to allow for the best of both worlds:
build things quickly but also allow for change later. I won't go
into how this works, in detail.

But you're simply totally mistaken about the cuture of engineers –
there's quite a few engineers who have a very creative, exploratory,
"hacking" culture — even transgressive (see the free software
movement for example). It's easy to cast people in various
oversimplified stereotypes, but really, go look and see what's really
out there, who these people really are, how they really think, rather
than simply making various assumptions based on just a cursory
understanding.

Mitsu

On Sep 14, 2006, at 12:04 PM, Steve OR Steven Read wrote:

> I agree, that exploratory coding can be good!
>
> Its interesting that coders and engineers, in general, are
> materialistic, with this idea of defining an exploratory process as
> 'hacking'. That is the accepted thinking, that unplanned coding is
> dangerous, unprofessional, and leads to 'bad design'. I disagree,
> in terms of coding as an artist. If you are making software to run
> businesses, then yes I guess its hacking. For art, then NO. That is
> akin to saying that someone who is making a painting with zero
> preparation or structure, is hacking the painting. They are just
> painting, not hacking. Some people are good at that sort of
> process, others have the painting all worked out before touching
> the canvas. Either way works and can lead to 'good painting'. Same
> with code, some are keen with preparation and abstract design,
> other just want to code and let the coding process bring them
> somewhere. But the materialistic software world would call that a
> 'hack'. To me, its not. That word doesn't make any sense here. Why
> can't the mistak!
> es, bugs, weird design decisions, unplanned diasasters that are
> barely corrected, the human neurosis and error be part of the beauty?
> +
> -> post: [email protected]
> -> questions: [email protected]
> -> subscribe/unsubscribe: http://rhizome.org/preferences/
> subscribe.rhiz
> -> give: http://rhizome.org/support
> +
> Subscribers to Rhizome are subject to the terms set out in the
> Membership Agreement available online at http://rhizome.org/info/
> 29.php
>
>

Thanks for the reply. I totally hear what you are saying. I don't expect most engineers to like what I'm saying.

'hacking' can also mean "to hack away". Meaning something akin to this 'exporatory' process, as opposed to actual hacking in the reverse-engineering or security sense.

Actually, I am senior level software architect. I have coded for over 20 years and have written probably a million lines of code at least. I know this culture quite well! What I mean by materialism here, is that people say "this is the right way to do it, the best way, tried and true, if you don't do it this way, it is bad or wrong or could be better". In general, yes, that is how engineering is. There are sound principles to follow. These are useful in most cases. Materialistic here, meaning snobbery as the quality is judged by how they feel the material should be used 'best'.

Once upon a time, painters in the renaissance were the same way. "this is painting practice, tradition, this is how you do it correctly, this is how you do perspective and figures, mix paints, and so forth". They were materialistic about painting. Then along comes modernism which changes that and opens it up. Nowadays, paint can be used anyway a person wants - there is no correct way or "best practice" really. (Yet I would add, there are still today millions of painting snobs out there who scoff at certain usages of paint) Actually painting at this time was almost more a science than an art, wonderfully blurred boundaries back then.

I talk about painting because I paint, for many years, as well as coding. I love both. The process is similar. The material somewhat similar, believe it or not. Now what I mean here, is that what if I want to use the material of software code in whatever weird stubborn way that I want? I am an artist, can I not use the material and any way I desire to get an effect? What happens then? Sure - the program won't be easily maintainable, hard to read, unmodularized, unextensible, redundant, slow, buggy all these things perhaps. But so what? What is the result? Is the result expressive? Useful? Nonsenes? This is art code. Not business code. Meaning the 'horrible' and eccentric code and software takes on a whole new personalilty. Much like the early modernist painters did.

And I am not talking about code itself as end product, but in the execution of the code. I believe this is possible and worth investigating, what I am saying here. But I'm not quite yet sure what I am saying really. I'm just tired of engineers and their code snobbery, even though when I act as 'engineer' for money, I am somewhat of a code snob.

steven

Quoting Steve OR Steven Read <[email protected]>:

> 'hacking' can also mean "to hack away". Meaning something akin to
> this 'exporatory' process, as opposed to actual hacking in the
> reverse-engineering or security sense.

This, traditional, sense is the one I intended in my comment on exploratory
coding. I wouldn't call the modern mis-use of the word as a sysnonym for
"cracking" the *actual* sense, but sadly it is the one that most people know.

http://en.wikipedia.org/wiki/Hacker_definition_controversy

Happy hacking! ;-)

- Rob.