Oh hell yes.

[kickaha]

So as part of this death march in miniature, I'm having to submit a sufficicently chunky (~5kLOC) chunk of infrastructure code to a group of coders who aren't really design savvy. They're good functional coders, but large scale abstractions seem to give them a bit of fits.

So I wrote the original code in C++, for good reason. Got told no, they changed their minds, it needs to be done in C.

So I rewrite it in C.

Now I'm staring at this now ~8kLOC chunk of code (yes, there's a reason OO languages help you write more efficiently...) and wondering how the &*(%#$ I'm going to chop it up into meaningful incremental patches to give to them.

Because they won't accept a big patchbomb. (Ok, I can't blame them on that front, but it's damned annoying.) And each patch has to compile and pass regression testing. And they have to OK it. Which means it has to make sense to them. Dumping the whole thing at them is going to make them run in terra, so I have to lead them down the garden path gently.

So... how to go back to the original code, then artificially create patches that *lead to* the final design in a well-formed and meaningful way? Because my original design growth path won't work.

I'm using Subversion (it rawks my world) and have the C++ version off in its own branch, and the final C version in another, each moved out of trunk as it was finished.

The plan was to then start back with the original mostly blank slate from the group CVS repository (yes, it's under two management schemes right now - don't look at me that way, it works), and then start adding chunks as necessary, ensuring at each stage that it still worked. This has been, to put it lightly, a royal fucking pain in the ass.

Then it struck me just a bit ago.

Why not do it backwards?? Removing code should be easier to do than *adding* code, IMO.

Plop the *finished* C code into a new branch. Tag as Anti-Patch 0.

Remove a piece of code. Compile. Tag as Anti-Patch 1.

Remove another piece of code. Compile. Tag as Anti-Patch 2.

Continue this until I *end up at* the original code. Tag as original. Assume it takes M steps.

The last checkin prior to the original code will be Anti-Patch M-1. Retag this as Patch 1. Anti-Patch M-2 becomes tag Patch 2, and so until Anti-Patch 0 becomes Patch M.

Now... here's the fun bit. Start going *chronologically backwards* but *logically forwards* through the tags. Check out tag Patch 1. Send diff patch to CVS repository.

Check out tag Patch 2. Send as diff patch to CVS.

Continue this until I hit Patch M. At that point I can switch to the C branch (now moved into the trunk) and be on my merry way, with the CVS repository and my private SVN in sync. Use SVN to manage local changes until they're ready for submission, and then tag each as it goes to CVS.

This should be *much* easier... and at each publicly submitted stage, it looks like I did it on *purpose*. :D

Intelligent design? No, this is intelligent devolution.

Comments

[kaneda-khan.livejournal.com]

Ugh. Sort of like the Antinews section of the Emacs manual:

For those users who live backwards in time, here is information about downgrading to Emacs version 20. We hope you will enjoy the greater simplicity that results from the absence of many Emacs 21 features.

[kickaha.livejournal.com]

EXACTLY!

And yet, not at all alike. :D

[georgmi.livejournal.com]

This is exactly why I chose test as my concentration, rather than dev. 'Cos after some poor schmuck like you spends a week figuring this kind of thing out, I get to spend five minutes playing with it and say, "Hey, thanks, great job. Except, you know that one variable thingy? The one you initialized twice? Which wouldn't be a big deal except the second time you initialized it, was kind of after you'd written data to it. Are you sure that's what you wanted to do? Because it kind of, you know, crashes the system when you try and read the data back out."

You know?

[kickaha.livejournal.com]

Ayup. I've been told more than once that I should be a tester. I can break anything. It's one of the things that makes my code nicely robust - if there's a way to make it misbehave, I've probably anticipated it.

So yes, I over-engineer the crap outta things. :D

[georgmi.livejournal.com]

Ah, but testers don't break things--we merely find the places where they're already broken and point them out.

Sorry, knee-jerk there. I've been told too many times late in a product cycle that I am (or my team is) "finding too many bugs" and thus putting the product in danger of slipping.

To which my response is _always_, "Would you rather have the customer find them?" The bugs are there whether I find them or not.

Of course, at some point, the pressures of the market determine that, yes, it's time to let the customers find the bugs on their own. So I spend the last six months of the product cycle getting beat up at work for finding too many bugs, and the first six months after release getting castigated by the press and the customer for not finding enough of them. (Of course, half the bugs the customers encounter are bugs I've already found but which were not deemed important enough to fix.)

And all because people buy into the shorthand "testers break things".

Not that I am bitter. :)

That said, I'm frequently going to my boss and telling him about the latest thing I've "broken".

I just hate to see testers getting beat up unfairly for poor-quality software releases, so I have to take the opportunity to get my side of the story out there.

[kickaha.livejournal.com]

LOL

No worries. :) Perhaps I should have said "I can see the boundary cases that others don't and exploit them." :D