Comment by taylodl | Hacker News Reader

Comment by taylodl | Hacker News Reader

Parent Full thread

I've seen this with my own two eyes. When asked why they removed the unit test they said after they made some rather extensive code changes the tests were failing so they deleted them. Nor was there any trace of irony in their response. When asked didn't they realize that was the whole point of having unit tests they replied that they knew, but they had deadlines to meet and there wasn't enough time. Since controls had been put in place to not ship with failing unit tests but not to check for test coverage they took the easy way out and deleted the tests. I informed management what they had done and thankfully they were relieved of their contract and their consulting company was informed what they had done. I don't know what happened to them after that.

Thing is, once the PM was informed what they had done we did a couple of sprints where we restored the unit tests (which we still had in our history) and got them passing. They had no idea the consultants were doing such shoddy work in order to meet deadlines. The upside of all this is to this day that PM now actively checks the Jenkins dashboard to see the current state of tests and that no tests have been deleted - and that's for all his projects not just that one particular projects. Now that the story is part of our IT lore the new consultants get the message loud and clear we're not afraid to send them packing.

In the end this turned out to be a good story for us - but wow.

> The upside of all this is to this day that PM now actively checks the Jenkins dashboard to see the current state of tests and that no tests have been deleted

I just hope that story doesn't continue in the future with something like:

  @Test
  public void testFoo(){
    /* Original testFoo() code here. */
    assertTrue(true);  // Unnecessary bloat.
  }

Been there, seen that.

Always assume that consultants will never perform any task that isn't required for milestone sign off.

I'm a consultant; this is good advise.

It's not laziness or apathy. It's just that we're only paid to do a task.

> It's not laziness or apathy. It's just that we're only paid to do a task.

That's contractor-talk.

If you're a consultant, consult. Educate your client, make sure they understand the consequences of what they're not paying you for.

Sometimes it's a tough sell. I work for a consulting company that I think would rate as very high quality. We try to bake it into contracts and sales pitches that we work a bit slower because we don't cut corners. This isn't always appreciated by a client who's rushing to market. If you think about the old project management triangle, it's scope, budget quality and you can only have 2 out of 3. If you have a contract with fixed scope and budget, it's quality that goes. Getting a client to sign a contract with flexible scope is not easy unless you have a ton of credibility.

"Rushing to market"

Reminds me of the kid going "I want to play, I want to play".. sorry George you suck at basketball, go shoot some free throws.

"You won't believe one startup's new growth hack, their teammates hate them!"

Good luck explaining the point of unit tests to technology illiterate managers - they don't understand and really they shouldn't have to.

I always use double accounting from finances to explain tests. You don't do logic changes in one places, but in a second to double check it actually works out.

Thanks, I'm a consultant and will use this analogy in the future. I apologize to all the in-house developers, we truly try to sell in quality but it's extremely hard to convince technologically impaired managers this, especially when the budget is fixed.

Thank you for this -- it will be put to almost immediate use.

Sounds good, if only I understood double accounting :-)

The principle is simple. Basically your entire accounting log is always a balanced equation: sum(assets) = sum(liabilities) + sum(owner's equity). Every transaction gets recorded on both sides of this equation, so you can check for (certain kinds of) mistakes by adding up everything on both sides and seeing if it matches. This is a vast oversimplification, and possibly slightly wrong, but hopefully illuminates the connection with unit testing. :)

The article and this subthread talks about "unit tests", but i think it's really functional or acceptance tests that would have been valuable in these cases. I think it's entirely reasonable for product owners to have some exposure to those.

No, they really should.

The American notion of "manager" is somebody who has ultimate power over the work. The American notion of "employee" is basically "minion"; they are supposed to do whatever they're told. You see it over and over on HN, and even in this thread: developers believe they are supposed to do whatever the boss/client says, even if they know that will lead to disaster.

With power goes responsibility, so if managers want to boss people around, they must understand unit tests and all the other sustainability-oriented development practices.

The alternative, which I would prefer, is that developers start acting like professionals. E.g., like doctors or structural engineers. Those people have codes of ethics and see themselves as having a professional duty. When people ask them for something that's dangerously bad, they say no.

But until that happens, managers really should learn how to manage the stuff they're claiming authority over.

> they don't understand and really they shouldn't have to.

They shouldn't have to because they'll listen to us and allow us to write and maintain tests as we develop, right?

My take on this is that automated tests is a developer tool and doesn't matter to them. As much as they shouldn't care which text editor we use, they shouldn't need to know that we write tests. In fact I tend to avoid as much as possible commits that only impact tests in case they would look at the SCM history and be tempted to blame tests for a delayed delivery (no "fixed the test suite" commit messages). Also I never explicitly count automated testing in my estimates, it's counted implicitly as part of normal development.

"They're a way to check that nothing is broken" doesn't get through to them?

Hopefully not, because it is completely wrong. They are a way to check that what you test is not broken, which is usually not even remotely the same as "nothing is broken". I have seen so many pieces of code that didn't work in the real world but had many unit tests, good test coverage and were therefore "high quality" - yeah, sure.

Ok, fair point. It still seems like the potential benefit is pretty clear.

Why are they managing tech then?

I agree.

Both consultant sales dudes and customers are responsible for putting shitty SOWs together.

I hope you never consult for any company I work for.

Well of course. If unit tests aren't in the requirements, and it sounds like they are not, why do them? You have a dealine, people want you out of there asap, you don't start doing extra work. That is going to piss off everyone.

Most companies don't value tests, and it sounds like these guys didn't either.

That story had an unexpectedly happy ending.

Several times in the past when I've needed to complain about external consultants cutting corners, I've found the consultants have got in first and told my own management about their unique red-tape cutting powers, and how things like continuous integration (yes, the first thing they did was to switch off the CI server so no-one knew what was happening) were a time-consuming luxury.

Regarding the manager's response, are unit tests any use against someone who's trying to circumvent them? If a test passes a couple of values into a function and checks the result, wouldn't the "attacker"/programmer just hardcode those expected results into the function for those input values? Perhaps because that kind of code would look obviously suspicious?

My experience is that if you can cheat the tests in this way then they are either too narrow in scope, or badly written tests. This is something that TDD tries to expose when being adhered to strictly, that is, do the simplest thing to make this test pass - if you `assertTrue(isEmpty())` then I can simply `return true` to make you improve your tests.

If a consultant writes assert(isEmpty()) then the first thing I'm going to do is fire up version control, find the consultant and have them fired.

Reply on news.ycombinator.com