Elegance in software

Should software be written elegantly simply for the sake of it? I thought the answer would very much have to be a resonding "Yes!", but of late, I have come across trying to convey my belief to other people in an actual project, where time and productivity are measurable and very much not on our side. This experience has led me to question the extent my own stance, in terms of how much it compromises the overall worth of the software - I still can't help but think that the answer is still yes, but I wonder what we can say about the software in question - if one takes the artistic approach and look at the grand, sweeping notion of "generalized software", then the question is, I think, the same as asking whether art should be beautiful for the sake of it. But if one looks at the dark, grimy (no, I'm just being facetious!), practical component of software, then things don't seem so clear.

In the wonderful software project I have wasted my last few weeks on, we have come towards the finishing stages, which, given the somewhat unusual nature of our project, meant that we had to in essence "throw away" (Brooks all the way!) three of our four code bases. We were faced with a seemingly simple decision - go with an approach that offers structure over trivialities (again, half-serious) such as actual features, or go with one where there is considerably more that can actually be done, in terms of viewable output, but where the structure was definitely of secondary importance (which, as it goes with these things, led to a relatively weak structure). Two guesses which way I wanted to go! (Although, I have a tendency to wax lyrical about anything, so it should come as no surprise that I fear that I have lost any shred of respect among my group well before the ensuing discussion)

The others thought it better to proceed with the tool that looked like it could do more, and I thought it would be simple enough to try and convince them of why I thought that wouldn't necessarily be a bad idea. But, as I proceeded to do so, I realized that I wasn't getting anywhere - my arguments were being countered on the basis of pure pragmatism. After all, who cares what's down underneath, as long as it works, right? The "do whatever makes it work" idea, which I am not a fan of.

I initially thought it to be all too easy to demonstrate why this was an unhealthy approach, but it wasn't working. I slowly started to imagine myself as a passive observer of my own comments, and they started to strike me as hopelessly idealistic - not that that's a problem as of itself. No, the problem was that I started to see things clearer from the other point of view, and it became worrying that the more pragmatic view began nullifying my arguments. After all, with my head-in-the-clouds approach, searching for the lost pattern and the house of four doors (pick up that reference - go on, try!) and what have you, the very pertinent question is this - with the finite amount of time available, and with the very real hurdle of assessment at the end, what can this approach produce that is of directly observable value? Hey, hold on, this can't be - they were starting to make sense here...!

The key here is how exactly its worth is measured - classicist or romanticist, you take your pick. I think I somehow feel it is being measured by no-one in particular, as though there's some fundamental spirit to whom we owe elegance to be strived for. But hey, is that any kind of talk you can make to a group of normal people!?! In the hum-drum world of assessment, unfortunately, more worth is invariably placed on what can be seen. It's very much the practical side of software that is stressed on, which is good, since otherwise they wouldn't be doing their job. But what I see to be the more interesting side of it is somehow deferred, as if it is either of little importance, or it is somehow intuitively obvious. So, knowing this, it seems pretty fair to say that the logical choice is the one where more can be shown, right? Ahhh, but if only you knew what was going on below the surface...! As you can see, I haven't fully wrestled out this problem.

The more I thought about it, the more I realized that I was in a discussion with people who have completely different - but, surely, equally valid - views about software than I do - people who, quite justifiably, take the more utilitarian view. Functionality over form. (Not to suggest that form is entire meaningless to them, but rather, given a choice between the two, functionality takes precedence)

Thing is, both views seem to have their place, in different contexts. The safest answer seems to be that one must strike a balance between the two, but one can't really strike a balance between choosing one of two options (which is quite literally what we had to do - this is no false dichotomy, so there is no way we could reject the choices as being incomplete!). But really, I am beginning to worry that the practical concerns are much larger than I had anticipated. Can one really justify taking the artistic view to the software as a whole (not restricting onesself to a single module or anything) where there is an actual client waiting for something (s)he can see do whatever is required?

How funny that this allegorical divide for two different approaches to software should rear its head at a time where I began to wonder if there is any resolution between the two!

I'm probably taking it all too seriously ("That's the story of my life / That's what Billy said / Both those words are dead", etc.). After all, I don't know that they would say the same thing had we been given all the time in the world (and, for some reason, decided to work on this very strange project...!). They're just being pragmatic, right? Well, yes, but I still can't come to terms with the attitude - alas, I seem overly fixated on these pristine notions, which probably have no place in practice.