Take Time to Go Fast

Imagine that you have to drive a long distance as fast as possible. Do you just jump in your car and put your foot down?

  • You won’t get there fast if you run out of fuel. You need to take time to fill up.
  • You won’t get there fast if you have an accident. You need to take time to drive safely.
  • You won’t ge there fast if you have to come back because you’ve forgotten something. You need to take time to pack properly.
  • You won’t get there fast if you pick a poor route. You need to take time to look at the map / program the SatNav.

We all know that, when driving, we need to take time to go fast.
Why don’t we understand the same thing about writing software?

HTML CSS and Real Programming Languages

It is a universal rule:
Wherever people talk about web programming languages:

  1. Someone will mention HTML and CSS
  2. Someone else will protest that HTML and CSS are not programming languages

But, does it matter?

A True Story

I once spent a few months developing a complex performance management system using a “proper” programming language. It automated the process of gathering data from various other systems, performed various manipulations on that data and then presented the results in a simple table, a kind of balanced scorecard.
Once it was live, a senior manager saw a tool written for a similar business, and asked if we could replace what I had written using their alternative. Furthermore, he was upset that I’d spent weeks developing my solution, where this new app had been written in a matter of days.
Further investigation revealed that the manager’s preferred option was all presentation with no substance: there were lots of colours and icons and graphs, but there was absolutely no logic behind them. All the data had to be gathered and manipulated manually. Despite the pretty interface, the application was essentially useless.
I’m happy to say that the manager in question was persuaded that my approach was the one that met his real business needs.

The Importance of Real Programming Languages

Now, as any CS graduate will know,  “real” programming languages are Turing Complete. As a proper sad geek, I find this sublimely fascinating. It means that, for any program written in a T-C language, a functionally equivalent program can be written in any other T-C language. Of course, this isn’t to say that all languages are the same. The each have their strengths and weaknesses that make them more or less suitable for certain tasks. However, I/O aside, this means that all programs can be written in all true programming languages.
Of course, the same isn’t true of a markup language like HTML or CSS. In fact, there are whole classes of problem that these languages simply can’t solve. Where I can program anything I want in a true programming language – including layout engines – it just isn’t possible to achieve the same things with languages that aren’t T-C.
(As an aside, some people think that the fact that HTLM and CSS are declarative rather than imperative actually nakes a difference here. But, that really isn’t the point. It is possible for a declarative language to be T-C and for an imperative language to be not T-C)

The Importance of Presentation

Unfortunately, when programmers get sniffy about HTML and its ilk not being true programming languages, there is often an implication that skills in HTML, CSS etc. are somehow inferior to skills in “real” programming languages. This is a serious mistake.
In my story, the senior manager felt that design was very important to him, to the extent that he was initially prepared to overlook function in its favour. Now, if this were an isolated incident, I might suggest that the manager was just being foolish.
But it wasn’t.
Time and again, I’ve met users who are impressed by flashy graphics and whizzy widgets, but unimpressed by raw functionality and my technical achievements. I think that there are several lessons to learn here:

  • People evaluate software on criteria that they understand. They often understand the difference between good-looking and ugly, but rarely appreciate technical nuances.
  • People are fooled by appearances. This may not be a good thing, but it is a reality that we must live with.
  • Appearances influence the way people feel about software. The way people feel about software is important to them. Indeed, people sometimes prefer software that makes them feel good over software that is functionally superior. Indeed, they might well be more productive with feel-good tools than with technically superior tools. To this extent, our users are not being fooled. They are actually making a wise and thoughtful choice.
  • As programmers, we often neglect the role of presentation as we focus on function. To some extent, this is right and proper. However, it is important to recognize that there is another dimension to our work that is important to our customers.

So, presentation-oriented languages (HTML, CSS) are important. The value added by tose who can use these tools effectively should not be underestimated.

What is the Difference, Really?

The interesting thing is that, to most people, none of this T-C business matters. The important difference between a programming language and HTLM / CSS is this:

HTML and CSS describe presentation, whereas programming languages describe function.

And both of these things matter.

Why are Programmers Pedantic About it All?

So, why do programmers spend so much passion on defending their position that HTML and CSS are not programming languages? There are lots of reasons.

  1. Because there really is a real and fundamental difference, as outlined above.
  2. Programmers spend a great deal of time, effort and money developing their skills. People naturally value the things in which they invest (“your heart is where your money is”).
  3. Programmers often feel the need to justify the amount of time it takes to produce results compared to the rapid results achieved by UI designers. In order to do this, they need to draw a distinction between what the two groups actually do.
  4. Employers need to apply the right people to the right jobs. Unless we clarify the (often technical) differences, managers easily make the wrong calls.

Is it Always Appropriate to be Pedantic?

Let’s face it, as programmers we’re a naturally pedantic lot. It goes with the territory. It doesn’t help that many of us have been burned when non-programmers have failed to understand what we do.
Nevertheless (and to be honest, this goes against my natural instincts), I don’t think we need to call people out whenever they slip over every little distinction.

The important things here are context and perspective.

I’m told that, to a biologist, a tomato is a fruit. But when I buy them in the supermarket, I look for them amongst the veg. Why? Because the technical distinction doesn’t matter in that particular context. Moreover, the distinction would actually get in the way if I daft enough to include tomatoes in a fruit salad.
It is the same with computer languages. There are times when the difference between programming languages and other languages really does matter. Quite often, however, we can all communicate perfectly effectively when just lump them all in together. In the case when people are asking what programming languages they need to lear to do web development, it really didn’t matter what languages were true programming languages and which were not. Pointing out the distinction won’t advance the discussion in any way. Indeed, in many cases, pedantry can stir up negative feelings and damages relationships… as my wife will gladly testify!

When to Make a Stand?

A preacher friend of mine once delivered a sermon entitled:

Is this a hill worth dying to be on?

He was referring to generals who make a strategic assessment over which battles are which fighting: are the gains worth the costs?

  • Is it really worth interrupting the flow of the discussion to make this distinction?
  • Does my pedantry stem from a sense of arrogance or from past hurt?
  • Do my comments value the skills of others as well a my own?

Of course, there are times when distinctions need to be made. My aim is that, when I make a contribution, it will add value to our collective endeavours.
That is, after all, the job of a every real programmer.
(This article is based on my answer to a question on Programmers)

Because there really is a real and fundamental difference, as outlined above.

BizTalk: Problem with Business Rules not Working

The Problem

If you’re having trouble getting Business Rules to work, remember that you can test your rules in the Business Rules Composer. Microsoft provides details on how to do so on MSDN.
However, I recently found that the business rules that I was testing were known to be correct (they worked on another machine) but were not being invoked on my PC.

The Solution

The reason that they were not working was because my PC was not configured correctly. I needed to add a new DWORD registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BusinessRules\3.0\StaticSupport = 1
Richard Seroter’s blog gives more details on the purpose of this key.

Practice: Don't Repeat Yourself (DRY)

Description

To eliminate information repetition of all kinds.

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. Andrew Hunt and David Thomas (2000) The Pragmatic Programmer

This does not only apply to code:

  • Copy-paste (surface features of the code are the same)
  • Logical / Functional (the same logical process, but surface features vary)
  • Data (the same information in two different places)

But also to:

  • Documentation (requirements, for users etc.)
  • Software architecture
  • The software development process

To help you remember this practice, write out 100 times, “I will not repeat myself”.

Solutions

  • Repetition in process calls for automation
  • Repetition in logic calls for abstraction

Alternative Names

  • Single Source of Truth (SSOT)
  • Single Point of Truth (SPOT)

Forces Against

  • Ignorance of parts of the system (I didn’t know it was already there!)
  • Reliance on surface information rather then deep understanding. Assumption that is different because it looks different.
  • Reuse of existing information from several non-colsolidated sources.

Problem Overcome

  • Duplication requires that all copies must be maintained
  • Leads to larger code / data base, making finding defects more difficult

Contraindications

  • Automated derivation (eg. caches, generated code / documentation) where the original source is well know.
  • Certain optimisation techniques

Part of Development Lifecycle

  • All

Related Practices

  • YAGNI

Examples

  • Code reuse: Classes, subroutines, code libraries
  • Data Normalisation
  • Design Patterns

References

  • N/A