Work for an hour after breakfast and take the train in after the rush hour.

Although I often try this, we usually end up having team meetings early in the morning, due to time zones (we have team members in England and Spain). My commute is about an hour during rush hour, maybe 40 minutes on off times. Thankfully I work from home a lot.

I don't understand what you're trying to say here - the code written by weaker devs, if they introduce unacceptable bugs, will not pass tests written by better devs in this scenario. And no, at no point are good tests about rewriting the program. If not automated tests, what exactly is your strategy for creating large systems (say, over a million lines of code) and making frequent changes to such systems without breaking them all the time? Empirically speaking, automated tests are how we manage to ship large complex systems without breaking them all the time. It seems strange to me that you have these strong opinions about how automated tests aren't effective, yet you don't seem to have any experience with or suggestions for shipping large complex software at low defect rates and large tech companies manage to do this, while heavily relying on automated tests.

I went in at 2, traffic was a breeze. Coming home at 5 sucked. Long day.

It should be a given that you have developers who are able to write code that meet whatever standards that are set and enforced by the team. If not, you're not going to deliver but this doesn't have much to do with bugs in production. If it does, then you have bigger problems and you should fix that first.

This kind of thing is mostly irrelevant at scale and doesn't have much to do with defect rates but more with velocity. If your tests care whether loops and string manipulation use idiomatic python or not, your tests are bad. Also, your job as a test writer isn't to write tests that confirm what the current implementation is doing, but to write tests that verify whether the code under test meet the expectations, implied or explicit.

Most of this just feels like you've had to deal with code written by others and not having done this much in your career, you are having a difficult time relative to the standards you have for yourself. That is fine and you will learn to deal with this over time but it doesn't have much to do with the challenges faced by the industry in terms of defect rates and shipping frequently without breaking stuff. You have to think through what it is that you're trying to achieve here and consider everything through the lense of shipping working software to customers. Here you're venting about the things that are making your work difficult but making your life easy is not the same thing as shipping high-quality software. "People are writing code that I have a hard time understanding" is not a software quality problem per se.

Obviously there is a dissonance between the realities we deal with. I'm not sure if you quite comprehend the garbage I've dealt with. I'm not really "venting" as I enjoy the challenge of it, and I happen to think I'm pretty good at this stuff. And yes... this stuff sells a lot better than being a "data nerd."

It's not really about code quality per se, but about what the next person (or same person) has to do to fix the issues involved. There is a tipping point where the technical debt is too deep to do any reasonable fixes, and there's no amount of testing that can fix that. As an example from a contract a few months ago, I was dealing with a macro that called a macro that called another macro (that's three macros, the initial and two "extending macros), just so the person didn't have to write two lines of code. Of course, the output was completely inflexible and... wrong. I couldn't easily strip it, or anything, out.

This gets to the crux of the issue. There is a level where the code gets so bad that no test can be written for it. The intent of the code isn't understood by the writer because they simply can't conceive what the correct output is supposed to be in the first place -- mainly due to poor fundamentals and a very poor grasp of how the language they use works. At this level, a change is no longer a matter of "change this and ensure the output is correct." The change is "the output is so off-base and poorly defined that there is nothing to test."

When a larger org already has some working program, it goes without saying that good tests will toss most of that trash out. The problem is that the testing has to be partly post-hoc. If the initial stuff isn't correct at all, you are writing tests that define an incorrect output. Garbage will pass all day, but getting straight A's in failure is still failure.

After all that writing, my experience is that before writing tests, I have to ask "what does this even do?" then I have to trace through the code. At this moment I often find a mistake, and I may as well rewrite it. Am I supposed to just write a test, tell them to fix the problem, and stall production?

Dave, no one is arguing that unit tests are magically able to fix all problems associated with software engineering - unit tests aren't going to replace bad code with good code, nor do they have the ability to fire bad developers and hire good ones in their stead. I'm not sure what it is that you're trying to say, but the point is that unit tests are cost effective ways to ensure that bugs that developers write into their code don't actually get shipped. Nothing you've said is a meaningful argument against that point. That people with cancer at advanced stages are going to die soon even with a healthy balanced diet isn't an argument against having a healthy balanced diet. That those people with cancer have had terrible diets all their lives is also not an argument against having a healthy balanced diet. It seems to me that you're seeing these horrible problems in code bases that don't have any unit tests - that's an argument for unit tests, not against.

This is an argument for unit tests - you can systematically eliminate such code by mandating that production code be accompanied by unit tests. Likewise, it's likely that much of the crap you've seen would not have passed unit tests, had such unit tests been in place in the first place.

I think we can also agree that unit tests written at point in time t + 1 cannot lower the rate of bug being introduced at point in time t. I think that's effectively the point you seem to be making with your examples and I fully agree. You're observing the code at t here and talking about how writing a unit test at t + 1 isn't doing anything about the code at t. But what if there were unit tests at t - u instead? Maybe that would have prevented some of the code you're seeing from being introduced between t - u and t. That's how you should measure the effectiveness of unit tests.

You seem to be saying that unit testing can somehow enforce better designed code. This would assume that I have free reign to re-architect the code, which I do not always have to power to do.

Mayhaps I don't have the creativity to really design a good test suite, at least not the type you are describing. I'm not sure if unit testing would help in the situations I'm describing. Writing a good test implies you have sane input and output. I just don't see that as a given in many cases.

You go first, don't hold back.

Don't even get me started on the great SonarQube battles at my company. Actually I can't really start because I don't know much details. Just that devs were hiding from sonarqube (you can tell it to ignore code somehow) huge blocks of code that it would have otherwise flagged, which of course made the DevOps team unhappy.

Devs complained that SonarQube was unfairly flagging some things and they don't always have time to go to the DevOps SQ team to get to the bottom of it.

Management sympathizes with DevOps position' that code quality is not optional, but we have production deadlines to get features out the door and we're already way behind.

You said that.

You're saying the code couldn't be this bad and have unit tests written for it. Thus mandating unit tests in the first place would have enforced some very minimal level of quality.

This has nothing whatsoever to do with whether unit testing is effective. Like I said, I agree that a healthy balanced diet won't cure cancer and your unit tests won't retroactively fix a terrible code base. You're just some guy who's told to do some stuff - you're not going to magically save a bad dev team from itself. That unit testing doesn't confer this magical power to a contractor to single-handeded save a terrible code base doesn't mean unit testing isn't an effective best practice. And like I said earlier, most of this just seems to be about you having a hard time understanding your role and accepting that you're one guy out of many and that you're not going to make or break the project.

No one is saying unit testing will magically save a dying code base maintained by a terrible team.

If you could read you would see that Dave and Candy are talking about two different things which they are calling the same thing. This will lead to lots of talking past each other. If they had taken a minute to talk about what they meant when they say such a slippery buzz word as "code quality" it would at least get them on the same page.

Do they mean syntactically pure code that compiles with no warnings? Do they mean chunks of code that are black boxes hiding everything but the interface from external entities? Do they mean a continuous integration development environment where bugs can easily be rolled back if they are not automatically caught by automated testing? Do they mean code that has passed rigorous QA scrutiny or that developers support their own code so they are motivated to not generate any calls? There is a lot of wiggle room in that phrase which is why if your going to use it you should be able to define what you mean by it.

Edited to add. One thing that is pretty clear though is that code quality can't be bolted on later, if it's not part of your development life cycle your going to end up in trouble. At the start up I was with it took cutting the company in half and spending close to a year to catch up on the all the tech debt we had been building into our product. That was a year with virtually no feature enhancements just fixing stuff we hadn't had time to do right the first time. Larry, that's why I'm saying it's unlikely you'll find time to go back and fix what you know is done poorly now.

I haven't talked about code quality and it has nothing to do with my point, which is that automated tests are effective ways to ensure low defect rates in production. The issue is more that he's confusing "tests can't fix all problems" with "tests aren't effective." It's a strawman that he's been attacking - no one is saying that tests will automatically fix all problems. Also, it's important to understand, at his level of experience, that his experience does not necessarily generalize and that his perspective, even for the specific situation he's in, does not necessarily reflect the actual situation.

More specifically, it's clear to me that his statements about tests are more about his feelings of helplessness around the tasks that he's been assigned with and not about the effectiveness of tests per se. Everything he's talking about is centered around how things are making his job difficult and offending his sense of aesthetics - nothing about his comments indicates that he's considering the situation from the perspective of shipping products with low defect rates.

Apparently reading isn't one of your strong points.

Quote:

Originally Posted by candybar

I haven't talked about code quality and it has nothing to do with my point, which is that automated tests are effective ways to ensure low defect rates in production. ...

Your post is just blathering. LOL at your post being anything resembling a working definition of code quality.

I'm talking about both code quality and testing. I don't feel like candybar and I are talking across each other. This conversation is very helpful.

Unrelated to the previous conversation but my experience is that most of the things engineers do to "reduce technical debt" often do very little to address fundamental problems. Most of the time, "technical debt" is some combination of "product design debt" (which I've talked about before ITT) and organizational incompetence - the former can't be solved by engineering teams on their own and the latter limits the ability of the team to do much better than they did before. In some cases it may be worse because "technical debt reduction" is rarely something that merits significant engineering resources in most organizations so often partial rewrites designed to reduce technical debt are even more rushed than the original product. I've lost the count of times I've seen such efforts increase technical debt further and/or worse, introduce serious reliability issues due to the resulting frankenstein architecture. I'll also add that people tend to view their own kludgy hacks as clever engineering accomplishments and others' kludgy hacks as technical debt.

I'll give a simple definition of code quality:

Does it follow the official documentation? If not, then it's not good.

There are a few languages that I'm good enough at that I can practically write it in my sleep. I'm well-aware of the pitfalls and traps one would ram into when writing incorrect code (defined as not following the official docs) since I've done it so many times myself.

Using my definition may sound simplistic, but I think it's the best measuring stick to quickly look at something and guess how likely the code has a bug in it. It's a proxy, but code that widely diverges from the official docs indicates a programmer who doesn't know the language very well. This will result, more often than not, in code that has hidden bugs because the programmer in question doesn't know the base language and he doesn't know the pitfalls of divergence. This is why I'd prefer to see programmers write their own tests. Breaking and building go hand in hand.

I wasn?t defining code quality adios I was pointing out why it wasn?t easy to define, if candy doesn?t think he was talking about it and Dave did it still makes my point.

What do you mean by official documentation here? Or for that matter what do you mean by "follow" in this context?

This is wrong on two levels - 1) this isn't anywhere near as important as how the problem is broken down at a higher level - you can write perfectly idiomatic code that follows all the rules that is nevertheless an extremely poor way to tackle the problem at hand; and 2) you redefined "code quality" more or less as "things I'm good at" which is highly problematic from the perspective of learning.

Also, when you design large systems and run large organizations, you're going to be the one writing official documentation and style guides. Relying on the existence of some third-party tool that tells you how you're doing doesn't really work at some level.

wtf test

I mean, it's all nice and good that we can write any language in Ruby syntax, but the samantics of Ruby -vs- other languages are different enough that this devolves to a massive mess. I'm not buying that you really can't take the time to read a few pages of documentation from (www)my-favorite-lanaguage(org) just to at least get an idea of how every other programmer who RTFD writes the language. I'm not talking about internal style guides, I'm talking about absolutely ****ing up because you couldn't wrap your brain around the fact that you can't write a Java for loop in Haskell.

That sounds a lot more like a pet peeve than a design philosophy

This may be a hiring issue or a technology choice issue. Either your devs are simply unable to program at the level expected for the problem domain or you chose the wrong technology to use - if your devs are more comfortable with Java, use Java, don't use Haskell or Ruby. It may also be a daveT issue if they developed a reasonably coherent standard that works for them but you're having trouble reading their code because you are used to a different style - this is common for multi-paradigm languages such as C++, Scala and Ruby as there's no clear "right" way to do things. You keep complaining about for loops and that may be a sign that it's more of a daveT problem than otherwise.

Btw, I don't mean "a daveT issue" in the sense of there's something wrong with you in this case, more that if N developers are used to style X and 1 developer is used to style Y, the easiest way to resolve the problem is for that one developer to get used to style X. And in this hypothetical scenario - hypothetical because I don't know if this is indeed what's going on - you may be that one developer.