Tech in the 603, The Granite State Hacker

Functional Expression

So one more thing crossed my mind about implementing code with respect to art & science, and I had to express it…

I looked up the term “Art” in the dictionary. The first definition is:

  • the quality, production, expression, or realm, according to aesthetic principles, of what is beautiful, appealing, or of more than ordinary significance.

For me, regarding coding, it’s a matter of remembering a few points:

  1. implementation is expression
  2. significance is subjective
  3. beauty is in the eye of the beholder

So code can be expressed, fundamentally, in a bunch of ways:

  • Electronically,
  • Numerically,
  • mnemonically,
  • symbolically,
  • graphically,
  • gesturally,
  • audibly,
  • visually,
  • etc… ?

Simple, clever, elegant, seemingly natural expressions of all kinds are typically beautiful to a programmer, when they function correctly.

Of course, to me, the most beautiful implementations are implementations that elegantly express its business in a way that’s very clear to anyone familiar with the problem domain at that abstraction level, and to the target platform(s).

See also:
politechnosis: Art & Science

Tech in the 603, The Granite State Hacker

Artless Programming

So maybe I am strange… I actually have printed snips of source code and UML diagrams and hung them on my office wall because I found them inspirational.

Reminds me of a quote from The Matrix movies…
Cypher [to Neo]: “I don’t even see the code. All I see is blonde, brunette, red-head.” 🙂

It’s not quite like that, but you get the point. There’s gotta be a back-story behind the witty writing. I suspect it has something to do with a programmer appreciating particularly elegant solutions.

One of the hard parts about knowing that programming is an artful craft is being forced to write artless code. It happens all the time. Risks get in the way… a risk of going over budget, blowing the schedule, adding complexity, breaking something else.

It all builds up. The reality is, as much as we software implementers really want application development to be an art, our business sponsors really want it to be a defined process.

The good news for programmers is that every application is a custom application.

It really sucks when you’re surgically injecting a single new business rule into an existing, ancient system.

This is the case with one of my current clients. At every corner, there’s a constraint limiting me. One false move, and whole subsystems could fail… I have such limited visibility into those subsystems, I won’t know until after I deploy to their QA systems and let them discover it. If I ask for more visibility, we risk scope creep. The risks pile up, force my hand, and I end up pushed into a very tightly confined implementation. The end result is awkward, at best. It’s arguably even more unmaintainable.

These are the types of projects that remind me to appreciate those snips of inspirational code.

Don’t get me wrong. I’m happy there’s a fitting solution within scope at all. I’m very happy that the client’s happy… the project’s under budget and ahead of schedule.

The “fun” in this case, has been facing the Class 5 rapids, and finding that one navigable path to a solution.

See also:
politechnosis: Art & Science

Tech in the 603, The Granite State Hacker

Art & Science

Fire & Ice… Day & Night…

This question, Art vs. Science, has come up a million times in software development circles. Reading Paul Johnson’s (Paul’s Pontifications) blog post, in conjunction with a discussion in the Tech Mill at Edgewater, (thanks, Jason!) I have come to see that art and science are not as opposite as I once viewed them to be.

What hit me was that Paul makes the statement that there’s no process to implementing software. I still disagree. There are many processes.

The number of processes that an implementer can choose from to write his/her code is often vast, and depends on the problem set. A problem set includes many things, including requirements, tools, target platform, development platform, existing code, and even the implementer’s mood and frame of mind. That is what makes implementing code, like painting, or creating a recipe, an art.

Within a common implementation problem set, there can be a large number of processes which can be applied to derive valid solutions. In fact, there are so many, that some distinct processes may actually render the very same code. So, to be more clear, it’s not that there’s no process… it’s that there’s no single valid process.

Knowing that there’s no one single valid process doesn’t mean that we can’t pick a needle from the haystack… if the process produces a solution within the problem set, it’s good.

Now consider what happens when you start to narrow a problem set. There’s lots of things you can do. Frameworks, platforms, clear-specific requirements, best practices, coding standards, well structured architectures… these things are all factors that limit the problem set. By narrowing a problem set, you narrow the number of valid processes. By narrowing the number of valid processes that a developer can choose from, lots of interesting things start to happen. You achieve more predictable results, and are more likely to achieve repeatable schedules… and you reduce overall project risk.

This is what’s so interesting about contemporary trends in software development, such as Ruby on Rails… use of these tools narrows problem sets that developers face. This means the implementer can spend less time figuring out where the blanks are, and more time filling them.

Now let’s take this further. What happens when you reduce the problem set dramatically…? Take a single, relatively well known problem, on a very specific platform, using a very small set of unambiguous expressions. You get a very tightly defined process. By doing this, you wring the art out of creating something, to the point where it becomes machinable. The process becomes realized as a factory.

So to answer the question… Art or Science?

It’s a trick question… art and science are not exclusive opposites. Art is about freedom to choose your creative process. Science is about knowing what processes are available, and the pros and cons of each. So programming, like all creative activities, is usually art (except in single-processed cases), and usually science (except in cases of serendipity and true miracles).

Paul’s Pontifications: An Under-Appreciated Fact: We Don’t Know How We Program