Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Careless" employees

niniane.blogspot.com

Post reply on HN
Print view View original

41–50 of 83 posts

Re: "Careless" employees

#41

Post by collyw »

16s wrote: post #5

Great read. This sentence sums it up best I think, "Why, why, why would people expect to get great results if they flaunt all the best-practices that have developed over the past 20 years?"

Ok, I will go out on a limb here and say that I don´t unit test (at the moment), as I estimate it would take at least twice as long to write the test code and data as the actual code, as there are many related objects that need to be put together correctly for each test case. I am in the fortunate position of writing an in house Django app, so basically it is in a constant beta state, and I have around 40 beta testers to tell me when things go wrong.

Now I see that unit testing would have caught a few of the bugs over the last couple of years (but not that many of them) but in our case, adding new features and adjusting the data model to the constantly changing requirements is more important. My code does get tested, just not automatically.

I am not saying that it is a bad idea to unit test, and that I never intend to use it, but for the time being the time costs don´t outweigh the benefits.

Also whenever I look at tutorials there is no advice on how to test the parts I want to test. Instead they demonstrate how to test 2 + 2 = 4. I don see the point in that when my application is mainly outputting a moderately complex SQL query results. I can generate a load of objects in the database, and set up unit tests, and have them run each time I update a completely unrelated part of the application, or I can use the real data, and check the results are as expected on my development machine. I know which way is more productive for me.

Re: "Careless" employees

#42

Post by chris_mahan »

AndrewKemendo wrote: post #21

I think these are all fantastic things to implement but do you know how much pushback you get from engineers on this: Me: "Do you have a standup every morning, so that you know about schedule delays after at most one day?" In general folks HATE these, but I would love to hear other cases where people have found them successful. We are small enough that the conversation is ongoing so haven't needed to implement it. Wh…

I hate it because some people on the team come in at 6, others come in at 9:30, and anything in between. Some leave by 3:30, and others leave from 5 to 7 pm. I was at work last night until 11:30, working on a particularly gnarly task. (different schedules, because different lifestyles, different obligations -- remember, diversity is good).

When we need to talk to people to find out what's going on, we just talk to them.

Re: "Careless" employees

#43

Post by scott_s »

collyw wrote: post #41
16s wrote: post #5

Great read. This sentence sums it up best I think, "Why, why, why would people expect to get great results if they flaunt all the best-practices that have developed over the past 20 years?"

Ok, I will go out on a limb here and say that I don´t unit test (at the moment), as I estimate it would take at least twice as long to write the test code and data as the actual code, as there are many related objects that need to be put together correctly for each test case. I am in the fortunate position of writing an in house Django app, so basically it is in a constant beta state, and I have around 40 beta tester…

"Unit" and "automatic" tests are not synonymous. We have a non-trivial system, and mocking the necessary components for unit tests seems like a productivity loss to me. But we absolutely have automated tests; we don't test components in isolation, but as they will behave in production.

However, carefully crafted system tests can exercise the parts of the system you want to exercise. You know the little examples you write up yourself to convince yourself that a new piece of functionality actually works? Turn those into tests, and keep them around. I have been saved by those when a seemingly unrelated change caused an error in something I had not anticipated.

Re: "Careless" employees

#45

Post by chris_mahan »

buckbova wrote: post #38

We've tried to institute technical design docs and reviews and failed. Management keeps asking we do them but doesn't enforce it. Developers don't want to do it and take it personally when you suggest a different approach during the review. Management sets deadlines on projects without consulting leads or architects. I (database architect) have suggested we add steps for technical approval and code reviews to our fea…

You need to read "Good Boss Dead Boss".

Re: "Careless" employees

#46

Post by mkramlich »

Early impressions of the article:

some of that is getting what you pay for. If you go after cheaper or younger people, you're more likely (all other things being equal, general case, etc etc) to get lower quality work. Also, there's a self-created problem factor where if you force somebody else to give you an estimate (which is just a guess however much you pretty it up and repackage it), and then turn that around and treat it as a deadline, then you can expect those deadlines to go whooshing past. And it will happen even more often if you have cheaper/younger/less-experienced programmers.

Hire better people, which also means paying them more. And don't ask for estimates. Just see what happens, and iterate.

Re: "Careless" employees

#47

Post by jeremyjh »

collyw wrote: post #41
16s wrote: post #5

Great read. This sentence sums it up best I think, "Why, why, why would people expect to get great results if they flaunt all the best-practices that have developed over the past 20 years?"

Ok, I will go out on a limb here and say that I don´t unit test (at the moment), as I estimate it would take at least twice as long to write the test code and data as the actual code, as there are many related objects that need to be put together correctly for each test case. I am in the fortunate position of writing an in house Django app, so basically it is in a constant beta state, and I have around 40 beta tester…

>I know which way is more productive for me.

How do you know this? It frankly doesn't sound like you have worked on an application of similar scope that has good test coverage. I went the first decade of my career without writing tests and said the exact same things you are saying.

I do agree that learning how to write effective tests is difficult and that you cannot do it by reading the web tutorials and the scant coverage given in most books. I learned how by working on an existing project with good coverage.

On my own personal projects what I began doing was writing tests instead of writing most of the exploratory code in the REPL, or instead of writing a stub of a template to test some new code in the browser. I took all that ad-hoc scaffolding that naturally pops up and just structured a little bit and called that my tests. My tests are more integration tests ... I still do not understand the compulsion for low-level unit tests that do nothing other than prove the underlying framework works correctly.

Re: "Careless" employees

#48

Post by shalmanese »

timr wrote: post #33

Yeah, code review is great...until you find out that some of your reviewers are rubber-stamping the commits from their favorites, and a large percentage of the rest are doing a sub-standard job of reviewing, and pretty much everyone is just barely finding the time to do the (decidedly un-fun) chore of reviewing code, instead of writing code. So you're back to the root cause of the problem: you have to hire good peopl…

The solution is code meta-review! Just have reviewers review the quality of reviews until review quality is up.

Re: "Careless" employees

#49

Post by hackula1 »

scott_s wrote: post #43
collyw wrote: post #41

Earlier quoted context omitted.

Ok, I will go out on a limb here and say that I don´t unit test (at the moment), as I estimate it would take at least twice as long to write the test code and data as the actual code, as there are many related objects that need to be put together correctly for each test case. I am in the fortunate position of writing an in house Django app, so basically it is in a constant beta state, and I have around 40 beta tester…

"Unit" and "automatic" tests are not synonymous. We have a non-trivial system, and mocking the necessary components for unit tests seems like a productivity loss to me. But we absolutely have automated tests; we don't test components in isolation, but as they will behave in production. However, carefully crafted system tests can exercise the parts of the system you want to exercise. You know the little examples you w…

I tend to have strict unit testing with near 100% coverage for libraries. For application code, I use primarily sloppy integration tests. This seems to be the right balance for me anyway. That being said, I try to extract as much app code into libraries as possible.

Re: "Careless" employees

#50

Post by thirdtruck »

chris_mahan wrote: post #45
buckbova wrote: post #38

We've tried to institute technical design docs and reviews and failed. Management keeps asking we do them but doesn't enforce it. Developers don't want to do it and take it personally when you suggest a different approach during the review. Management sets deadlines on projects without consulting leads or architects. I (database architect) have suggested we add steps for technical approval and code reviews to our fea…

You need to read "Good Boss Dead Boss".

This book? http://www.amazon.com/Great-Boss-Dead-Ray-Immelman/dp/097403...
Post reply on HN