When I started my career many moons ago at SGI, I discovered that there was a set of really smart folks who viewed software development not as an engineering discipline  but more akin to developing mathematics, or writing poetry.

There is a certain intellectual appeal to such a notion. If software, is indeed poetry, or beautiful, then that means that computer scientists are not merely engineers building devices using well defined rules, but we are artists creating something that has enduring value.

More to the point, it means that the software itself has intrinsic value beyond that of the particular product that it ships with.

So as software craftsmen, our job is not to merely satisfy the immediate customer requirements but to develop the perfect set of software that had enduring value that also happens to  meet the customer requirements.

For some reason, this never really worked for me. At some point, software is good enough, not perfect, and we need to move on to the next problem.

What appeals to me about software development is the part where the end product is used by someone to solve a real problem. I want to engineer, which means to make tradeoffs, a solution that people want to buy.

I am not interested in understanding what can be developed within the constraints of computability.

And in many ways, I am beginning to think that the software as mathematics crowd tends to have a dim view of software as engineering, because they are not engineers and don’t see beauty in engineering.

Which puts me in a different camp from the software is beautiful camp. I am in the camp that views the pursuit of software beauty as an end unto itself, a waste of time.

Now lets be clear, it’s not that I think software can not be perfect or beautiful, I do. Nor does it mean that I think that there is no distinction between beautiful software and butt ugly software, I do. And thanks to the discipline that those great engineers instilled in me at SGI, I think I was actually able to approach beautiful code.  It’s just unclear to me how the pursuit of this perfection got me any closer to my revenue goals.

I find beauty in products that exceed customer expectations, that are cheaper to develop than was expected and are easy to evolve at a low cost. I view the underlying software as a means to that end, but not the end in and of itself. And yes, I do  understand that sometimes it’s elegant beautiful software that makes that possible.

I think the art of engineering  is to understand where to invest your time and energy to get meaningful product differentiation and where to just live with problems. And I think it’s an art, because you never really know if you pulled it off until someone, somewhere opens their wallet and forks some money over to you because they want your product: not your software, your product.

Which brings me to the title of my blog. I think that there is a tension in computer science between engineering and mathematics. And I think that there is a a class of computer scientists who think of themselves as mathematicians building fundamental abstractions. And I also think that there is another class of computer scientists who think of themselves as engineers who try and deliver differentiated products that exceed customer demands with imperfect software.

And I think that between the two camps there can be no reconciliation.

When I started my career as a software engineer at SGI in 1996, I had the privilege of working with a great engineer.

This engineer and I had very different perspectives on software. I viewed software as a means to an end. As a vehicle to deliver the features that the were asked of me. That the perfection of the software was immaterial, what was material was how fast you could deliver those features. In fact, sloppy, disorganized, poorly structured code was okay as long as it worked. What was material was the function not the form.

He, on the other hand, felt that software was like poetry. That it had its own intrinsic beauty and that its beauty was an end in and of itself.

That’s not to say that he did not care about the outcome and the product. He was always passionate about delivering value to customers. He just felt that the elegant, solution was always better than the quick solution.

Being young, and he being great, I was convinced that elegance was worth the price in time and effort.

I’m not sure I still agree with him.

My career is littered with software systems that are no longer in production. SGI’s kernel was EOL’ed last year. NetCache was sold off to Bluecoat. Most of the code I wrote for DFM has been re-written as more and different requirements came into existence.

And he would say that is natural and normal and a reflection of the natural process of things.

And I wonder.

Was it really worthwhile to strive to create the perfect solution given the market pressures? Would I have been better off to just get the job done in the most expedient way possible?

Ultimately, I think the answer boils down to an engineering tradeoff. The perfect solution makes sense if you understand the requirements and the requirements are stable. But if the requirements change, then your attempt to create perfection has to be balanced against expediency and need.

Although I can appreciate a beautiful piece of code, I somehow am more inspired by a system that is easily adapted. A systems whose core abstractions although imprecise are in the right general area and allow for substantial independent directions of innovation.

Let me try this differently.

I think it’s far more valuable to know what the core set of abstractions should be and their general properties than to specify them completely. Instead of trying to perfect them in isolation, one should expose them to the real world and then learn. And if the abstractions were correct, over time they will get precisely defined and perhaps at some point become perfect, as they no longer evolve.

But I suspect that I will have long since moved onto the next set of imperfect abstractions.

And in retrospect, that engineer always remarked that it’s much easier to replace an elegant easily understood solution than a complex, baroque, over or under-engineered hack that was expedient.