Re: TDD, constant refactoring, good design, etc

Sasa wrote:

I agree. Why I asked the question - year ago I held internal presentation
at my company about refactoring. At the end, a colleague of mine asked me
fairly simple question - do I have some data at which point does it pays
off to refactor/test drive etc.

This is the kind of thing that only deserves a metaphor. Refactoring after
adding a feature is like cleaning up the kitchen after making dinner. The
next day you can make dinner in about the same amount of time, but
eventually your quality and velocity will go way down!

And I basically had no answer other than reasoning similar to yours. Now,
my colleague is a programmer and he understands that clean, thorough
approach is better. He saw too much rubbish, too much spaghetti to know
better. But what if you talk to a non developer manager? We had a
situation where manager had asked - do you need these automated tests,
none of other projects uses it and they are still shipped successfully.
What do you then?

Show them how your velocity will start high and remain high over time -
especially with much, much less debugging.

Another question - consider that your company starts development of a new
project. Let us say that requirements are roughly known. Let's also assume
that you decide to use unit tests. How do you estimate? How do you sat
when will you be finished? Do you incorporate unit tests in the estimate,
given the fact that ca. twice as much code must be developed? What about
constant pair programming - do you also double the estimate?

Even if the requirements are known, you must sort them in order of business
value. That's also a design technique.

And you estimate by running one iteration with "whatever" estimates, then
measure its actual rate.

You are finished when your code passes its acceptance tests, and when the
whole team agrees to their quality and scope.

You don't need to "incorporate unit tests into the estimate", because they
are easy to write, and because they prevent hard endless debugging. They are
what help make the estimates accurate and useful.

And only one developer owns a task. When they start the task, they call for
a pair, maybe for a trainee, or maybe for someone who knows the module they
must interface with. Pairing is simply assumed into the estimates, and the
whole team owns the sum of the estimates - not the individual programmers.

Yes, I basically agree. In the practice however, we actually had solution
where we compromised quality, on behalf on time. That means, we chose
solution which was less attractive to the customers, but more time
effective.

Do you mean you compromised on scope - the volume of features? If so, did
you ask the customers which scope was most important?

I'm really not sure about the fact that quality shouldn't be variable. As
long as this quality doesn't mean much to the end user, it is as good
variable as any of other parameters. I've heard of cases where end users
said: "Ship as soon as possible. We are aware that there will be plenty of
bugs, but we want to try it under our fingers, and really need this piece
of software ASAP."

That sounds like you wrote the features they actually needed a while ago,
but didn't deliver. Then you "put off" a bunch of things like support
features, installers, reports, etc. Then you tried to cram them all in and
went late.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!


.

Relevant Pages

  • Re: SproutMethod.pdf
    ... Design Paterns book) (i.e. through Factories, ... Refactoring and the other techniques that I write about are in fact ... security and other essential features were lost on the ... > I know how to write good programs sometimes, using mathematics, but as you point ...
    (comp.object)
  • Re: OOP/OOD Philosophy
    ... > I agree that TDD strongly resists certain types of defects. ... so they will prevent this mistake while refactoring. ... When you implement features in order of descending business priority, ... helping the Onsite Customer write acceptance tests, ...
    (comp.object)
  • Re: Does good programming come with experience ?
    ... Not doing the necessary 'refactoring' in preparation ... have benefited, by orders of magnitude, from automated unit tests. ... unit tests make reinventing wheels easy and safe. ...
    (comp.programming)
  • Re: OO Design, Physical Implementation, DAOs
    ... features at the same time would be more complication, ... Add unit tests to the existing code. ... Refactor the existing code - just a little - to emerge a couple features of ... the latent DAL layer, ...
    (comp.object)
  • Re: Unit Testing Non-Believer
    ... I have a harder time writing unit tests for existing ... I've gone out of my way to keep my UI and business ... This is one of the reasons I'm turning in to a big unit testing fan. ... it isn't practical without some major refactoring, ...
    (borland.public.delphi.non-technical)