Why Specify ?

I need a Specification for AIVIPI.

Keeping in mind that

• If I don't know what it is going to do then, sure as beanz meanz fartz, it won't do it
• I would like to test that these specifications have been met - so easy translation from specification to test case would help.
• I may not achieve the ideal specification on first draft

OK, enough with the caveats, let's specify:

The system shall:

1. Help me to code faster

"help" is less helpful:
    I'll keep it in the Hippocratic sense - "first do no harm"

Which is not as easy as it might seem - I'm a fairly fast coder when I get going, and pretty adept at vi. I have to be, because I am trying to use a mere text editor to edit source code. So it is going to be easy to get in my way.

"me" is nice:
    always a good idea to keep close to the customers

"code" is a good reminder:
    this is not a Software Engineering tool we are wrighting
    engineers use all kinds of other editors, vi is for coders

"faster":
    Hmm...
        Ick !
Not quite teh suck, but fairly ick nonetheless.

How am I supposed to make any real measurement of whether the system actually works, if "faster" is the criterion ? (Ar an lámh eile, I could make it even less real: "better" or "finer", or "hacker", or ...)

At least "faster" has pretensions towards measurability. But programmer productivity is notoriously impossible to measure:

• For every "KLOC/day" there is the wonderful feeling of removing KLOC, but leaving the same functionality.
• For every "LOC/minute" there is the line of python matching 5 lines of Java
• For every "issues per day" there is the "implement the system" issue vs the "missing colon on line 78" issue
• For every "tests per hour" there is refactoring
• For every metric there is a case where it does not apply

So, what else could "faster" mean ?

Well, there are some well-known coding cycles:

• edit - compile - debug
• code - test - refactor

whose iterations could be objectively measured, so maybe we could maximise the RPMs of such cycles ? Which leads to:

In which scenarios is increased RPMs of a coding cycle not a sign of faster coding?

• Well there's the minimal one : Alan makes no code change, <F9>, and <F9> again, and <F9> again, and I've still no idea why it is going wrong. So no idea which code to change, and indeed I would "code faster" by decreasing RPMs, slowing down by the amount of time it takes to change code.
• When Mary is writing lots of code, and hitting <F9> fairly often, but making no progress. Increased RPMs here is likely a sign of desperation. I would also expect that the amount of code being changed is small (and Alan is just the limiting case of Mary)
• When Fred is writing correct code. Once Fred is "in the zone" then he is less likely to make mistakes, and running for feedback is likely to be minimal and irregular. So increased RPMs might be a positive sign, or it may be negative.
• When Susan is learning a new language or API. She is more likely to make typo-level mistakes, so more feedback on these errors is helpful. Improvement is marked by less "little fixes", so on average faster coding means RPMs should be decreased
• When George is making steady progress. Of course Fred may be making as much, or more, "progress" as George, so we know it is George because he is hitting <F9> fairly often, and each <F9> adds tests passed. Increased RPMs may be due to faster runs as easily as faster code
• Helen is writing writing crap code, but is frequently trying out fixes - so is closer to George in how often she hits <F9>, and how balanced she is between coding and running. She differs from George in that the code she is changing is less likely to be new. But increased RPMs means the same as for George

And in which scenarios is increased RPMs a definite sign of faster coding?

• When Ann takes a lot of time to set up the test / run. If this set up time is decreased and all other times remain equal, then increased RPMs indicates faster coding.
• Harry is also writing a lot of code, he may even be "in the zone", but he is writing crap code. When he runs, he finds out it is crap. Increased RPMs must mean running more often, so he finds out it is crap more often.

75% failure rate on that idea ! Leaving me with no real way to measure how effective any enhancements from AIVIPI might be. Damn, guess I'll have to sleep on that one.

PS:

"ar an lámh eile" = "OTOH" in my native tongue

Hitting <F9> is my way of starting a build. (End edit phase, start test phase of a cycle)
PPS:

Tonight's soundtrack was "The Grass Is Blue" by Dolly Parton and "Sambo de Janeiro" by Bellini, so you should understand that there are more gaps in the text than may be apparent.