Re: [tlug] [OT] Good IT Resume

[Curt Sampson <cjs@example.com>]

On Sat, 28 Jul 2007, Josh Glover wrote:

> Ah, but you elided one important entry from that list, didn't you?
>
> 3. You work for a company that employs 4000 developers who are not
> you, but must interact with your code. Furthermore, you have many more
> constraints placed on you.

Hm. Well, let's try to summarize my impression of this whole thing,
here.

My original understanding of your argument was, "I always do a prose
specification, usually around ten pages long, for every project I do,
and I don't feel that any project will succeed as well without this."

My argument is that there are many projects that can succeed better without
this (though not by doing everything else the same, less that one document).
In particular, I think that:

    1. A specification that can be interpreted by a computer is better
    than one that can't, since it allows you to automate more of the
    process of determining whether you're meeting the spec.

    2. The actual code is form of specification (the one the computer
    uses), it's better to have just one spec than two, and in most cases
    if we're going to drop one, we should drop the prose rather than the
    code.

Now, I can certainly think of very strong reasons to write a ten page
prose specification, and when I encounter those, I write one. (The
usual reason is not that it makes the project work better, but that the
customer feels happier, regardless of the value to the project itself.)
But the time I spend producing that is time I can't spend on something
else, and I'm pretty ruthless about trying to do only the things that
produce the most business value, and many customers, if they can get
over their discomfort with not having a ten page prose specification
maintained for the life of the project, can get more business value
through producing other types of artifacts.

Outsourcing the coding of something, by the way, is another area where
you need to produce a detailed specification. That is why I often
question the value of outsourcing; producing and validating the spec is
often the vast majority of the work, so making that easier and doing the
coding yourself may very well be cheaper than spending more time on the
spec. so you can spend less time on the code. A lot of this depends on
what languages you use, of course: if you're coding in C, you probably
spend ten percent of your time dealing with things directly relevant to
the problem itself (the "essential complexity"), and ninety percent of
your time dealing with what Fred Brooks calls "incidental complexity":
checking error codes, tracking pointers, avoiding buffer overflows, etc.
In situations like this, my preference is to try to fix the language if
at all practical.

In fact, Paul Graham's article "Great Hackers" touches on this in the
"More than Money" section:

    Business types prefer the most popular languages because they
    view languages as standards. They don't want to bet the company
    on Betamax. The thing about languages, though, is that they're
    not just standards. If you have to move bits over a network,
    by all means use TCP/IP. But a programming language isn't just
    a format. A programming language is a medium of expression.

    I've read that Java has just overtaken Cobol as the most popular
    language. As a standard, you couldn't wish for more. But as a
    medium of expression, you could do a lot better.

> No hard feelings, mate; at least on this end.

No, of course not. E-mail between techies often sounds far more like a
flame war than it really is, so I don't generally take very seriously
any personal impliciations I might interpret from an e-mail exchange.
(Even "you're a moron" is more often a criticism of an idea, rather than
a person.)

cjs
--
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
Mobile sites and software consulting: http://www.starling-software.com