In writing software, whose job should be simplified?
I'm listening to JavaPosse #37 which is part 2 of their interview with Bruce Eckel. The interview is highly interesting and I highly recommend it. This is my first exposure to this guy, and it's clear he knows his stuff and is very articulate. Must be why his books are popular.
There's a thread in what he's saying that I want to respond to. Namely that a Good Language is one which makes it EASY for programmers to write code.
I admit, that's a very attractive thought. As a software author, I appreciate being able to write what I'm thinking, and when the language gets in the way of writing what I'm thinking then it's frustrating. He talks up new Java features (e.g. foreach) which help, and, of course, there's the languages like Python, PHP, Ruby, etc, which he talked about very glowingly.
But, let me ask you ...
What does the customer care about at the end of a project? You're delivering the application, and what's in their mind, what are their expectations? Are they caring how much fun you had with easily writing the code? Or are they caring about how well the application does the job they want?
I suggest it's the latter.
Which leads me to an idea ... whose job is it that should be simplified? The programmer or the tester? Or what about the new test driven development approach where programmer and tester is now rather merged? Which side of the programmers brain should have the easier time?
I'm not going to pretend to have a solution here. This question is being wrangled around in the software development field from all directions. But this is a point of view I don't see being discussed very often.
Is it important that the programmer be able to easily write code, or that they can easily write good code? And what about the job of the software quality assurance team?