Re: Setting boundaries in software development (robot menace)

[tye]

Having unthinking robots block work progress can certainly be a very bad idea. I have two main things that I weigh when considering such things:

1. How obvious and mechanical is the test being performed?
2. How serious are the consequences of violations getting through?

To a lesser extent, I also consider how likely violations are to happen. But that has more to do with whether some kind of check should be added somewhere in the process and not whether an unthinking robot should be allowed to block work progress because of a detected violation.

Unless the test is darn near impossible to get wrong, I'm quite unlikely to approve of an unthinking robot blocking work progress based on the test. Even for dead-simple tests, I'm against blocking work progress unless the consequences are serious.

For example, consider checking in a source file that contains tabs or trailing whitespace. It often isn't rocket surgery to get that test written quite reliably (you have to exclude "binary" files, and where you draw that line might be easy and obvious or might be completely unclear, depending on the repo involved). But I still wouldn't have the resulting unthinking robot in a position to block work progress.

I can convincingly make the case that such whitespace violations are against our best practices, that there will never be a need for them in this repo, that it is easy to avoid them, and that these violations cause problems down the road. But the consequences of violations just aren't even close to serious enough to block work progress. They aren't even serious enough to agitate your team members by having an unthinking robot get in the way of them doing their job (even if the robot offers a way to work around the check).

I much prefer to have the feedback on tabs in source code to come from coworkers who have the capacity to think, even contemplate. And I set the example of not providing such feedback mechanically nor incessantly. We don't need coworkers resenting each other as acting like unthinking robots. So getting feedback about tabs doesn't lead to agitation or annoyance or aggravation.

Checking in source code containing "\r" characters can be quite different. Having a future merge be pretty much impossible to resolve because every single line on one side of the merge is considered to have changed because a "\r" got inserted on each can be a very serious consequence. (I have not seen a person check in source code where they converted all of the leading spaces to tabs on every line when the coding standard suggests the opposite -- and if I were to see such, I'd want to have a conversation with that person, not just have their check-in blocked or produce a warning.) So I have sometimes had unthinking robots scan for "\r" characters in source code before a check-in is accepted.

Style? Oh, hell no.

I guess I could see it if I were working in a Java shop where the parser that enforces (or changes) the style is guaranteed to not just get it wrong in some way, we are using Java because it makes it easy to replace workers with minimal work by Recruiting, because we just find it too hard to mentor workers so that they become more than code monkeys, we prefer code written so that even entry-level java programmers can easily understand each line, we have so much turn-over that we don't bother fostering a good team feeling, so outright bickering about style is just to be expected unless you bring in robots that are even more unthinking than your coworkers...

Yeah, you deploy the style-enforcing robots in that environment. I'll go check the job boards instead.

I prefer documented best practices that encourage people to figure out ways to improve the best practices. It took a long time to figure out an indentation for moderately complicated conditionals that actually works well. I'd never have bothered if some robot was mechanically enforcing the formatting in the mean time.

Then there is the option of having unthinking robots rewrite your programmers' code and then committing the results, unseen by the programmers. That sounds pretty scary to me when the code is Perl. But then I've seen perltidy interpret code wrong quite a bit (most people seem to think that never happens).

My criteria for unthinking robots modifying code with the results unreviewed by real programers are similar to my 2 criteria above for blocking work progress.

This also runs up against my usual surprise when people talk about syntax highlighting. I spend about as much time looking at code outside of my favorite editor as I do editing code. Much of that time is looking at diffs. I don't get the casual acceptance of editing a transformed version of code that isn't going to match what I see in all of the other places when I look at the code. I go to edit the code and the line numbers don't even match those from the error messages because the code being run is straight from the repo while my editor is showing it to me with my preferred (un)cuddling of braces and/or 'else's?

No thanks! I prefer to foster tolerance and learning from each other, even when it comes to matters of style.