[Pdx-pm] sneaking tests into work
ben.hengst at gmail.com
Wed Feb 21 11:41:03 PST 2007
Kevin, that sounds wonderful... proper code reviews, what a dream
world you work in... sure to turn this ship around to something even
remotely looking like that here would be... well... many moons would
have to pass. Though I guess every little bit that I can do to help
will in fact help... so thats good.
And, wow, Schwern I think that you just described my current working
environment with that whole hairball thing...
I guess the plan is to figure out whats going to work out best for me,
and then do my own thing and then slowly try and get everyone else to
adopt some variation on the practice... slow and steady.... sloooww
On 2/21/07, Michael G Schwern <schwern at pobox.com> wrote:
> chromatic wrote:
> > On Wednesday 21 February 2007 08:17, Michael G Schwern wrote:
> >> The argument I like to use is that "non-productive" items like "commenting"
> >> or "indenting" or "version control" are not separate line items either.
> >> Why should testing be?
> > Because why would you write code that doesn't work? That's just silly. Don't
> > you know what it needs to do? What's all this "I'm done... I just need to
> > clean it up a little and test it" stuff? Either you're done or you're not.
> > Programmers tend to do a lousy job of actually communicating what it takes to
> > finish a feature. I wonder if we suffer from that when non-programmers
> > disbelieve us.
> Then you just don't mention it. :) Its a technical detail they don't need to know. Same as you don't mention that you're going to spend time commenting, indenting or using version control.
> If you really to need to argue the point, one way is to look at how many tasks are re-opened because it was "done" but later a bug was found and the task reopened. It could reopen at any moment. This sort of thing makes time estimates impossible, you never really know when its done. You can also point out that the time you spend fixing bugs (especially if you can find repeat bugs) would more than make up for the time spent writing tests.
> Another is to appeal to your users. How many tasks are bug fixes as opposed to new features? How many of those bugs were found by users? How often a is task is "90% done, I just need to do some testing" and how long does it remain in that state? This sort of stuff drives users bananas. Where I'm consulting they have employees who play the part of "on-site customer" so they have enough exposure to the dev process to have their voices be heard. If you sit down with a user and say "ok, what do you want your thing to do?" and write a test out of what they want they'll often be very impressed that a programmer is being attentive about a user's wants.
> Finally, there's often the hairball of code nobody wants to touch. Often its in the absolutely most critical part of the system. Payment processing is a common one. If it has no tests you have no assurance that your change didn't break things. Nobody wants to touch it because nobody wants to break it and take down the whole business. Nobody wants to clean it up because nobody wants to touch it. So it remains a hairball with its messiness spilling out into everything it touches (lava flow anti-pattern). Any requests for change to that part of the system are met with pushback from the programmers who don't want to touch it.
> Pdx-pm-list mailing list
> Pdx-pm-list at pm.org
More information about the Pdx-pm-list