Archive for November, 2008

Just say no to “software engineering”

I was reading Jacob Kaplan-Moss’s blog article on “syntactic sugar” and I realized that there’s something sitting just below the surface of what he’s saying, something important, something counter to the standard “software development is an engineering discipline” view of our work.

Jacob rails against those who say the differences between modern computer languages amount to nothing more than “syntactic sugar.” Ultimately he argues that: Syntactic sugar matters.

Sure it makes no “technical” difference but it does make a huge difference — because it changes the way we think about writing software.

I’ll loop back to that in a second, but first a quick detour through another recent blog post:

Eventually you come to realize that in order to truly succeed, you have to write programs that can be understood by both the computer and your fellow programmers.

Of all the cruel tricks in software engineering, this has to be the cruelest…. Even when you’re writing code explicitly intended for the machine, you’re still writing. For other people. Fallible, flawed, distracted human beings just like you. And that’s the truly difficult part.

Jeff Attwod

The thread that ties both of these together is that they highlight the way that people and by people I mean software developers, tend to forget is that code is always two things:

  • A series of instructions or declarations processed by a computer.
  • A series of instructions or declarations processed by one or more human beings.

Code is a machine construct, but it’s also a social construct. Software engineering is a strange name for our discipline, since the hard work of programming isn’t just getting code that machines can run, but in creating abstractions that allow human beings to learn, understand, and evolve the code over time. We didn’t invent Structured Programming, or Object Oriented Programming because they help the computer understand what we mean — we created them because they provide us with tools to help us as human beings to be able to understand the code we write.

Non-software Engineers aren’t concerned primarily with the practice of communicating complex thoughts and ideas to others. This is a vast oversimplification, but I think it’s fair to say that they are interested in constructing mathematical models of how things things behave, so that they can build stuff that works.

But that’s not what we are, we are creative writers, we invent new ways of thinking about the world, and we try to communicate them to each other every day.

Software Engineers do create incredibly complex systems, and operate under constraints that other writers do not — what we write has two audiences, one human, and one non-human. Writing for the non-human audience alone will result in code that’s incomprehensible to other programmers, but the opposite is also true. Computer programming is hard — and it’s hard for a very specific reason — because it requires thinking like other people, and not thinking like people at all.

Fortunately, the problem is simplified a bit by the fact that other programmers have learned at least somewhat to think like silicon and metal, so you can lean a little bit in that direction and still be understood. But still you have a very exacting, very alien audience, and a very exacting, very human one — and programming languages must be designed to balance the needs of both.

So, perhaps we ought to stop calling ourselves software developers, software architects, or software engineers, and start calling ourselves software writers.