Monthly Archives: December 2007

Christmas comes to Raynor Park!

Every year the Raynor Park Neighborhood Association invites Santa Claus to tour our neighborhood. This year, as our first vice president, I participated in the whole event. And boy was it a lot of fun.

A whole bunch of us got together to decorate Santa’s sleigh, a 38 year old truck that still has it’s original engine. 

IMG_2365

 

IMG_2371

And not only did we decorate Santa’s sleigh. We also decorated some of the lead cars that followed us:

IMG_2369

We even got some of his reindeer ready:

IMG_2374

Soon enough, however, Santa showed up ready to go. And we all tried to get our pictures taken with him. After all we’re all youngish at heart 🙂

IMG_2378

And then the ride around Raynor Park began. IMG_2386

 

As children saw us they would come out and greet Santa. Santa’s sleigh would stop and the kids both young and old would get their picture taken!

 IMG_2385

And even the four-legged variety were excited!

IMG_2388

Hopefully next year we’ll not only get more kids but we’ll also get more of our neighbors to join in getting Santa’s ride ready.

If you want to reach the Raynor Park Neighborhood Association send an email at admin at raynorshine.org

Math, Engineering and the field known as Computer Science

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.