Poet and critic Paul Valéry got to the heart of the relationship between art and business when he wrote, in 1922, “[For lovers of perfection], a work is never finished…but abandoned,” the act of abandonment being “the result of weariness or an obligation to deliver.” We software developers are, in the main, lovers of perfection–and we are subject to both weariness and pressure to deliver, forces that militate against at least some of our aspirations to perfection in our work.
In one sense, software must be perfect–it must run flawlessly–or it is nothing. But practitioners of the art of programming have idea(l)s of aesthetics and style and form that go beyond functionality. Even after we deliver functionally perfect code, we nonetheless feel, with Valéry, that we have abandoned the code. There’s more, sometimes much more, that we want to do with it: we want to make it more elegant, more idiomatic, more transparent to ourselves and to whoever looks at it next.
To the business stakeholders, polishing and refactoring code that already works can seem like a straightforward waste of time, an extravagance. It’s difficult to gainsay that perspective. Yet we’ve all seen cases where making the code beautiful, readable, and approachable pays dividends in saved time (and therefore money) down the road, when the same code is touched again.
Can our drive toward a second-order, post-functional perfection be good for business? There’s no simple answer. This talk will explore the question.