Re: Timeless Classics of Software Engineering

rem642b wrote:

> I agree. That's one of the winning things about interactive languages
> such as LISP. When I write LISP code, I unit-test one line at a time as
> I write it. When I have finished all the lines of a function, I
> unit-test that function for each of the different kinds of situation it
> must deal with. I include all my unit-tests as comments just after the
> end of the function definition, so later if I need to change that
> function I can re-do all those old unit tests and any new unit tests to
> make sure the function still works after the modifications.

Manual or automated unit tests?

> > The real hacker way to deal with customer requirements is to throw
> > them into the bit bucket ...
>
> An alternative is what might be called a "consumer-oriented hacker":
> The hacker inquires about the customer's real needs until he knows what
> tool the customer most urgently needs. Not a fullblown do-everything
> program, just one tool that does one kind of task and actually works.
> The hacker can typically make such a tool within a few hours or a
> couple days. Then while the consumer is beta-testing it, the hacker
> works on the next-most-urgent tool. So day after day the customer has
> yet another tool to handle yet another urgent problem.
> Are there any consumers interested in hiring me in this way?

If you refactor your code together between each feature, and if your bug-rate is absurdly low, and if each feature makes you faster, then what's the problem?

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces