The joy of enigmas

…thinking about an enigma. There it is before you—smiling, frowning, inviting, grand, mean, insipid, or savage, and always mute with an air of whispering, ‘Come and find out.’

— Joseph Conrad, Heart of Darkness

Visualizing language trade-offs

Guillaume Marceau has done some excellent work crafting the data from the venerable Computer Language Benchmark Game into visualizations that quickly show the trade-offs of using each language. The speed, size and dependability of programming languages puts each language in a small graph that simultaneously shows the execution speed and program size of each test for every language. From there, the characteristics of each language is manifest. He then goes on to consider whether functional languages display unique performance/size characteristics.

This is a must-read. It’s also great information design, proving that programming language esoterica needn’t bore the reader.

How did SQL get so popular?

Many developers, especially of the younger generation, dislike relational databases and their business-partner, SQL. It is regarded by some as the new assembly language. With all this distaste going around, how did it gain such a strong foothold in industry?

I offer you two answers: ACID and surface area.

ACID

Atomicity, consistency, isolation and durability. It’s not something most folks want to think about. To a rookie developer, it’s overwhelming. They’re not yet familiar with the semantics of the systems their programs run upon. Is fread thread-safe? “How should I know, I just learned C last semester and about fread’s parameters last week!”

The promises of a modern relational database include a compelling bullet point: your data is safe with us. Use our APIs, don’t break the rules, and we will make sure you never blow away some data and get a call at 3 AM. Rather, the DBA will, but what do you care about that guy?

So I submit to you that most programmers don’t use databases because they’re great. Rather, they have come to rely upon them because the canonical tome on transactions is heavy enough to maim small mammals and rife with formalisms. So they skip the nine-hundred page textbook and pick up the six-hundred page O’Reilly book.

Surface Area

Most programs that people will pay you to write involve side-effects. Further, many of those side-effects have to do with saving data off so you can perform further side-effects on it in the future.

The rookie developer typically leans first to files. Files are familiar and pervasive. But files leave a lot to said rookie. How should I structure my data? How do I load and save the data? How do I manipulate the data once it’s in memory? Even in scripting languages, with their simplified APIs, this means the rookie is faced with APIs like this:

  • fopen
  • fread
  • fwrite
  • seek
  • fclose
  • encode
  • decode
  • hash_set
  • hash_get

When I was bit a wee lad o’ programming, I found this Gordian knot difficult to cut. But then, one day, I was told by a programmer of greater wisdom to use a database. That API looked like this:

  • connect
  • execute
  • fetch
  • next
  • select
  • insert
  • update
  • delete

It was a lot easier to understand, even though the last four are a completely different language.

So, I submit to you, that SQL also won because it was easier to understand how one might structure their programs, make them work and, if they’re lucky, get them to run quickly.

Inflection point

I’d wager that five years from now, the generation of developers who are now upcoming won’t take the database tier for granted. Key-value stores, distributed file systems and document databases will all play into the question of “what do we do with the important data?” Sometimes, relational databases will prove useful. But increasingly, other things will too.

In the end, there’s two ways to look at this: we will soon throw down the shackles of our relational overlords, or, prepare yourself for the database renaissance in programming fashion that will occur in a decade or so.

Everyone wins!

When technical discussions get intense

Pro-tip: trying to unwind contentious technical discussions is a losing game. There are really multiple things going on: people discussing trade-offs in absolutes, personal vendettas being aired, missing tact filters and turf protection. If you’re lucky, there’s also some useful information hidden in the turd tossing.

Solution: don’t read too deeply, go do something useful instead.

Bonus tip: talking it out, face to face, over good drinks in a nice environment is “something useful”.

Developing fluidly

Here’s a raw idea I’m playing with in my head:

Agile development is great. But, if your team doesn’t map well to it, steal ideas from agile relentlessly.

You want a fluid environment where developers can solve problems (features, defects, chores) as they see fit.

Don’t use procedures to normalize productivity or as a communication protocol.

Do have a way to communicate things that need to get done or could possibly get done.

You need a safety net. Unless you know better, that safety net is some kind of automated developer test suite.

Enable developers, don’t direct them.

Discuss.

Read slightly less, practice slightly more

Chris Wanswrath, a smart and distinguished fellow, advises us to burn our news readers and just “hear it through the grapevine.” But how far can one go with that?

For myself, reading feeds gets me a few things:

* Aesthetic where I have none. Feeds like BLDGBLOG and Coudal point me to things that make me better at what I do, in a tangential way, and a more interesting person. These are things that otherwise I wouldn’t know where to start.

* Awareness on the edges. Reading folks like Simon Willison or Jason Kottke make sure that interesting topics in programming or erudition don’t go unseen even though I am focused on that topic.

* Aggregation of ideas. This cuts two ways. Most people worth reading compress a bunch of different sources down to a manageable stream. This gives me more bang for the buck in my feed reading time. On the other hand, if a link is mentioned several times in the aggregate of feeds I subscribe to, then its probably worth checking out.

I can see how following interesting folks on Twitter and reading aggregators occasionally can you get you some of this, but not all of it. With sources like Reddit or Hacker News, signal to noise is a problem – you can’t control who posts what. Some people have a lot of extra angst and/or spare time. Which is also the other side of the Twitter story. Some people are great to read, but a pain to put up with at times. So it goes.

When Chris’ essay first hit the wires, I was tempted to adopt his ways. But, I think I’m pretty good at ignoring the need to unbold things and cut down to business. What has proved immensely useful to me was has encouragement to just code all the time and make lots of stuff. I’m just getting started with this, but already I’m liking the increased feeling of accomplishment.

Regardless, we could all probably stand to trim our feed lists and hunker down on our projects, no?

Domain Driven Design

Designing software is a tricky thing. It’s tempting to front-load it on a project. That won’t work because the start of a project is when you know the least about it. So some folks try to do as little design as possible. I’m guilty of this. However, that can lead to software that doesn’t adequately express the problem it’s trying to solve. Further, there is often a temptation to over-design software with lots of ceremony and architecture. Contrary to this is the temptation to not design it at all, which again leads to software that doesn’t express itself.

There’s a book that draws a reasonable compromise between these forces. I’ve been meaning to read Eric Evans’ _Domain Driven Design_ for a while now. The emphasis of the book is in collaborating with domain experts and other developers to find the essence of the problem space and then express that in software (as objects). I’ve often pointed out the utility of building applications from the language up and the problem domain down. DDD focuses precisely on the latter.

One of the core concepts in the book is the _ubiquitous language_ that is used to describe the problem at hand. This language is used by the domain experts (customers) *and* the developers. The language is then woven into the design of the system. This leads to software that is more likely to succeed, both in business terms and in terms of development effort. Evans spends the first part of the book describing the particulars of this language.

He then moves on to describing the technical side of the software. Entities, value objects, services, factories, modules and repositories are terms I was already somewhat familiar with that Evans gave a more crisp and satisfying definition to. For most people, this is probably the tasty meat of the book, illuminating the way from a competent developer to an outstanding developer.

The last part of the book focuses on the larger scale issues of deep design. I was particularly pleased that he covers how software design is affected by various good and bad social issues. It also gives a strategic view of the forest, where most books on software development focus on a more tactical view of each tree.

I’m fond of pointing out books that are inflection points in my way of thinking about software development. Code Complete, The Pragmatic Programmer, The Dragon Book and My Job Went To India all fall under this category. Domain Driven Design is certainly the latest edition. It makes sense of trends I see in great software and illuminates a path to make software like it myself.

If reading this review didn’t make you want to vomit, you should probably read the book posthaste.