blog.frantically.org

From a variety of sources, this blog on the 5 Principals for Programming came my way. Two bits really grabbed me:

We know that c/java/lisp/haskell have not one bit of power that isn’t in simple assembly langauge–they only allow us to express the ideas more clearly and prevent certain kinds of stupid mistakes. There is no program that can be written in one that can’t be written in another, and all end up as machine instructions sooner or later (some at compile time, some at run time, but no matter). Given this fact it should be obvious that the only reason to have a programming language is to communicate to a person.

Absolutely, we could write in machine code but we choose not to. Why?

1. To make it quicker to write code.
2. To make it quicker to understand someone else’s code.

Often it’s too easy to concentrate on the first and forget the second. The less code we write, that clearly explains the problem it is trying to solve to another reader, the better.

But more often [as a developer], I know the best solution but it requires changing things. In my experience every single factor in the software development process will argue for doing the wrong thing: schedules, managers, coworkers, and even, when they get involved, customers.

Here I’m torn. Previously a developer and now manager it’s easy to shift focus from development problems to those of the customer. And the balance is hard.

There are certain tools that should always be used in development to create a system that is as flexible as it needs to be. These should be selected on merit but no matter what, the set will include tools for unit testing, repeatable builds, easy deployment etc. I’m assuming these are not up for discussion with the customer. We are employed to stop the customer having to worry about these details.

However, when using these tools, it’s easy to become caught up in the beauty, or purity, of the code we produce. But this beauty is not why we, as producers of software, are employed. It’s functionality is. Decisions on when to incur the future cost of poor implementation should not be made by developer alone. It’s easy to be upset when requested to do something less beautifully, and this is a good thing. Failing to understand the reason why it is important to do so is another thing.

I suppose the question becomes, “what choices regarding how software is produced should the customer get?”