Q: What if I'm designing and I'm not sure about some
implementation detail? If I write experimental code can I
count that as design activity?
A: Yes, as long as you discard the experimental code and don't reuse even a single line.
For example, say you want to create a string from an array of
characters, and the API shows the constructor:
public String(char[] chars, int index, int count)
You want to know what happens if count is greater than the
number of characters in the array. You try to find some
documentation explaining the answer but are unsuccessful.
So you decide to write a tiny program to find out.
public class StringSpike
{
static
{
char[] letters = {'h','i',' ','b','y','e'};
String words = new String(letters,1,10);
}
}
You can still consider this as the design phase, as long
as you delete the program when you find out what you need to know.
If you reuse even a single line, then we need to consider
this as coding phase, because it could have defects that
effect the rest of the solution.
Q: I'm not always certain which phase I'm in. Sometimes the distinction
between design and coding is vague.
A: Yes, this is sometimes confusing, because many students don't have a clear distinction in their mind between designing and coding. Usually this is because many students haven't been taught an explicit design notation, nor do they have clear criteria for assessing when their design is complete
Design is the intellectually demanding task of determining "how is this going to work." Design determines the algorithm that will solve the problem. Ideally the design is represented in a language independent notation such as pseudocode that has no syntactical details. Coding should be a purely mechanical task of translating an already completed algorithm into high level language statements. (Note that entering the design pseudocode as comments in the module has a fringe benefit of producing "pre-documented" code. This will spare you having to add comments to your code after the fact.)
Frequently as students attempt to construct a solution they write a mishmash of english and half-coded language statements. Regardless of how it is written, this activity of algorithm creation is still recorded as design. At some point when they have a general understanding of the solution, they will go to the computer and start typing in source code. This starts the coding phase. Even if mentally they are still refining details of the design "on-the-fly" so to speak, their subjective sense is that they have shifted to writing code, so it should be recorded that way. Another clue is that the visible activity is writing programming language statements so this should be recorded as coding.
Sometimes a confident student will feel like they understand the solution well enough that they can keep the design in their head and they don't need to write down the algorithm. If this happens to you, enter 0 for the design time and go directly to implementation. Of course Dr. Dalbey discourages this practice, but if that is what you actually do you should record it that way in your Log. During implementation you may decide you are in over your head and you need to go back to design. If you abandon your coding effort and go back to writing algorithms, record that you stopped coding. Count the next efforts as design time even though it comes after some partial coding you have already done.
However, if you carry out the design mentally "on-the-fly" during coding, count this time as coding. (Note that you will have probably still have to enter the design pseudocode as comments after the fact).
Ultimately this is a subjective judgement, so enter what seems most appropriate to you. If you conclude that you really did switch back to a design phase, enter your time that way. If, however, you are designing as part of fixing a defect or hashing out an implementation problem, record your time in the phase in which you found and fixed the problem. The criteria to keep in mind is initial design work is recorded as design, rework of flawed or inadequate design is not recorded as design.
Q: If I use the Eclipse IDE that compiles my source automatically, how do I record my coding time?
A: The first line you type into the IDE gets compiled, so count it as compile time. If you don't write your code on paper or in a text editor before you enter it into Eclipse, then there is no coding phase. If you go straight from design to typing in Eclipse, then enter 0 for the coding phase and put a comment "Entering/compiling code in Eclipse".
Q: During testing I have to re-compile my program after I've repaired a defect. Does this count as compile time?
A: No. The time you enter for the compile phase is the time you spend getting your program to compile successfully the first time. When you are first able to get a clean compile (no errors) the compile phase ends.
As you fix defects you find during testing, these changes must be recompiled; this time should be included as part of the test phase.
With some interpretive and 4GL languages (e.g. Python), there is no compile time. In this case, enter 0 for the compile phase and go directly from code to test.
Q: During testing I discover a design flaw. As I rework the design, does that count as design time?
A: No. Rework resulting from defects always counts as time during the phase in which the defect is found and fixed. Correcting code, changing the design, and re-compiling during testing all count as test time.
Q: In what phase do I record the time for writing test cases?
A: Record them in the phase you write them. If you write your test cases prior to coding, count it as design. If you wait until after coding to determine your test inputs and expected outputs, count it as testing.
Copyright © 2009 by John Dalbey