4 ms·

> Testing is really important, but few developers like to write tests. That means it’s your job. As a leader of an engineering team (and an engineer), I think

> Testing is really important, but few developers like to write tests. That means it’s your job. As a leader of an engineering team (and an engineer), I think the is this is entirely the wrong approach. It's a leader's job to get the team to understand why writing tests is important and have them write them. Sometimes an individual isn't a great fit on the team and you need to figure out how to handle it (i.e., they refuse to write tests but the rest of the team is). There are few points in this article that resonate - but there are many that are complete off base such as > Managers translate the project’s Big Picture into individual tasks for developers, with their details and interactions specified in minute detail I agree that leaders/managers translate the big picture to developers (provide vision) - but the team should figure out the minute detail - otherwise you're removing autonomy, the ability to fail, and are yourself falling into the pit of micromanagement.

sheepmullet 11y ago
"It's a leader's job to get the team to understand why writing tests is important and have them write them." And sometimes you shouldn't write tests, or perhaps no unit tests, or perhaps write the tests but throw most of them away, etc etc. It is all highly context specific. The real issue for managers is even if they start out technical, within a year or two they lose touch.
- chao- 11y ago
  Good discussion of this sort of thing in a series of recorded Hangouts between Martin Fowler, Kent Beck and DHH: http://martinfowler.com/articles/is-tdd-dead/ http://martinfowler.com/articles/is-tdd-dead/ The takeaway is that the usefulness of tests is the feedback it gives you about your code (and confidence, a subtype or result of feedback). All of the BDD vs. TDD vs. Test First vs. Test Whenever can get wrapped up in too much zealotry, and is ultimately secondary to the goal of getting feedback.
- mbernstein 11y ago
  Sure. I don't disagree about not writing tests at times, etc. That's different than the point I'm trying to make. Leaders aren't necessarily tasked with doing any job a developer thinks is shit. The leaders job is to help the developer understand the why behind doing it. Also, do you have anything quantitative to back your statement about being out of touch? That hasn't been my experience generally and I work quite hard to ensure I don't lose touch. That's obviously only data on my experiences - but I didn't make the assertion (I genuinely interested though).
  - hkarthik 11y ago
    Another recent engineer turned manager here. I can attest to losing touch, as I've had to work extra hard to see where things are trending in my spare time. If development wasn't also a personal hobby, this would be exceedingly difficult. Fundamental shifts occur in development all the time, and if you're not actively coding while these are going on, you can definitely get left behind and be out of your element when it comes to decision making. I have peers that cut their teeth on Enterprise Java and Oracle and now they are managing engineers doing Native Mobile, JavaScript Apps, Ruby on Rails, DevOps, Distributed Databases, and deploying on public clouds like AWS. It's very easy for them to get lost in the jargon and they end up leaning on and trusting senior engineers to guide them a lot. While this can be a good thing, it's very easy for the wrong senior engineer to lead them astray and start pushing their own agenda (rewrite all the things, resume driven development, etc).
    - mistermann 11y ago
      > While this can be a good thing, it's very easy for the wrong senior engineer to lead them astray and start pushing their own agenda (rewrite all the things, resume driven development, etc). This is a very good point, but how does an organization do this? Who can be at a management level for the majority of their time, yet still remain technically sharp enough in multiple technologies over time, to know when someone is outright lying to them? And it's not like you can just ask them to walk you through it - even ignoring the significant minority of egomaniac technical people who will more or less outright refuse such a request, in many cases even if they are relatively cooperative, often the subject matter is simply too low level or complex to be explained (or is deliberately explained in this manner), and sometimes the disagreement is not even a matter of fact, but rather a matter of opinion (everything XML, language choice, 100% test coverage, etc). It's a tough problem.
      - hkarthik 11y ago
        It's a good question, and a difficult one for me to answer as I'm still trying to figure it out. One possible defense against this is to regularly refresh talent, and encourage high performing individuals to swap between contributor and manager roles without any career penalties in between stints. Even if it doesn't work out for a contributor to manage people or a manager to write code, the cross pollination of talent could strengthen the technical capabilities across the organization. Contributors and managers would build trust with each other, and ultimately empathize enough with each other to act as trusted partners. I've seen this play out in the startup ecosystem as you see VPEs leave to become early stage startup CTOs, get their hands dirty to launch ideas, and then ultimately bring in trusted contributors once the products have found product-market fit.
fuuubar 11y ago
Your second comment, the one about autonomy, is the real insight that I wish more developers and managers would get. I almost quit reading the article upon finding the part you quoted. Thanks for pointing it out here! Way too often, real world discussions about management in teams turn into discussions about technical detail ("If we only had tests / quicker builds / used language X then we'd get better results") and this basic, underlaying problem of room for autonomy in the process is overlooked in favour of topics that are more easily discussed. The main reason I added this (mostly useless) comment was that all replies so far had followed the same pattern of only discussing the issue closest to technology; the tests. Edit: removed duplicated word.
developer1 11y ago
> few developers like to write tests I like how this statement completely skips the reason why developers don't like to write tests. The majority of managers refuse to allocate any time to write any tests. Hell, when we come up with a 6-week estimate for a project, they then tell us we must do it in 4. At 4 weeks, the complaints and blame game begins over why the project isn't completed. Why? Because it was a 6 week project, morons. I've only had one company with management that wanted unit tests written for code. Yet there was no official time dedicated to this process. That 6-week project that would be estimated without unit tests? Still 4 weeks. Huh? What magical world do you live in? Quality requires time. That 6 week project now needs 8-9 weeks. Not 4. Not 5. Find me management that understands this and actually cares about quality instead of impossible deadlines that fit their fantasy plan for the current quarter, and we'll talk. To be clear, I love writing tests. I would always have them if the decisions for project deadlines were left to me. Such decisions are out of my control, so the company gets what they are willing to pay for.
- vinceguidry 11y ago
  That's not the only reason. Writing tests is hard. Writing tests that are not highly coupled to implementation is hard. That means that every time you change the system, you have one or many test changes to make too. How do you know what to test and what not to test? How many tests do you write? One line of code can, if you think about it exhaustively, require 3 or even more tests. A lot of time you'll write code that facilitates testing. Do you test this code? What happens if the code silently fails and now you don't have proper test coverage of all the code paths said code is supporting? This is particularly true if you are mocking objects. Learning how to test, properly, is almost as hard as learning how to code. My advice is, if what you're doing is boring, like most Rails apps, lean on the library as much as possible, break up anything that goes against the grain into unitary features, and test them each in turn. You don't need to test that ActiveRecord.belongs_to works. It doesn't surprise me that there's developer reticence towards testing. I tried powering through that reticence, believing there's some "magical world" as you put it, where testing actually helps you code faster and more accurately, but I found even myself a TDD apostate, I don't even do it for my own projects anymore.
hn_user2 11y ago
> Not all of the tests, necessarily, but enough to set an example, set the standard, and get the ball rolling. I think you stopped your quote too soon. Writing a couple tests sets a pattern, an example o follow, and demonstrates how important they are because you are willing to take time to do them to begin with. But just giving lip service to the importance of them does not change a culture of untested code. Setting up code coverage reports, test harnesses, a few examples, and then talking about the test metrics shows it's important to management.

sheepmullet 11y ago

"It's a leader's job to get the team to understand why writing tests is important and have them write them." And sometimes you shouldn't write tests, or perhaps no unit tests, or perhaps write the tests but throw most of them away, etc etc. It is all highly context specific. The real issue for managers is even if they start out technical, within a year or two they lose touch.

chao- 11y ago
Good discussion of this sort of thing in a series of recorded Hangouts between Martin Fowler, Kent Beck and DHH: http://martinfowler.com/articles/is-tdd-dead/ http://martinfowler.com/articles/is-tdd-dead/ The takeaway is that the usefulness of tests is the feedback it gives you about your code (and confidence, a subtype or result of feedback). All of the BDD vs. TDD vs. Test First vs. Test Whenever can get wrapped up in too much zealotry, and is ultimately secondary to the goal of getting feedback.
mbernstein 11y ago
Sure. I don't disagree about not writing tests at times, etc. That's different than the point I'm trying to make. Leaders aren't necessarily tasked with doing any job a developer thinks is shit. The leaders job is to help the developer understand the why behind doing it. Also, do you have anything quantitative to back your statement about being out of touch? That hasn't been my experience generally and I work quite hard to ensure I don't lose touch. That's obviously only data on my experiences - but I didn't make the assertion (I genuinely interested though).
- hkarthik 11y ago
  Another recent engineer turned manager here. I can attest to losing touch, as I've had to work extra hard to see where things are trending in my spare time. If development wasn't also a personal hobby, this would be exceedingly difficult. Fundamental shifts occur in development all the time, and if you're not actively coding while these are going on, you can definitely get left behind and be out of your element when it comes to decision making. I have peers that cut their teeth on Enterprise Java and Oracle and now they are managing engineers doing Native Mobile, JavaScript Apps, Ruby on Rails, DevOps, Distributed Databases, and deploying on public clouds like AWS. It's very easy for them to get lost in the jargon and they end up leaning on and trusting senior engineers to guide them a lot. While this can be a good thing, it's very easy for the wrong senior engineer to lead them astray and start pushing their own agenda (rewrite all the things, resume driven development, etc).
  - mistermann 11y ago
    > While this can be a good thing, it's very easy for the wrong senior engineer to lead them astray and start pushing their own agenda (rewrite all the things, resume driven development, etc). This is a very good point, but how does an organization do this? Who can be at a management level for the majority of their time, yet still remain technically sharp enough in multiple technologies over time, to know when someone is outright lying to them? And it's not like you can just ask them to walk you through it - even ignoring the significant minority of egomaniac technical people who will more or less outright refuse such a request, in many cases even if they are relatively cooperative, often the subject matter is simply too low level or complex to be explained (or is deliberately explained in this manner), and sometimes the disagreement is not even a matter of fact, but rather a matter of opinion (everything XML, language choice, 100% test coverage, etc). It's a tough problem.
    - hkarthik 11y ago
      It's a good question, and a difficult one for me to answer as I'm still trying to figure it out. One possible defense against this is to regularly refresh talent, and encourage high performing individuals to swap between contributor and manager roles without any career penalties in between stints. Even if it doesn't work out for a contributor to manage people or a manager to write code, the cross pollination of talent could strengthen the technical capabilities across the organization. Contributors and managers would build trust with each other, and ultimately empathize enough with each other to act as trusted partners. I've seen this play out in the startup ecosystem as you see VPEs leave to become early stage startup CTOs, get their hands dirty to launch ideas, and then ultimately bring in trusted contributors once the products have found product-market fit.

fuuubar 11y ago

Your second comment, the one about autonomy, is the real insight that I wish more developers and managers would get. I almost quit reading the article upon finding the part you quoted. Thanks for pointing it out here! Way too often, real world discussions about management in teams turn into discussions about technical detail ("If we only had tests / quicker builds / used language X then we'd get better results") and this basic, underlaying problem of room for autonomy in the process is overlooked in favour of topics that are more easily discussed. The main reason I added this (mostly useless) comment was that all replies so far had followed the same pattern of only discussing the issue closest to technology; the tests. Edit: removed duplicated word.

developer1 11y ago

> few developers like to write tests I like how this statement completely skips the reason why developers don't like to write tests. The majority of managers refuse to allocate any time to write any tests. Hell, when we come up with a 6-week estimate for a project, they then tell us we must do it in 4. At 4 weeks, the complaints and blame game begins over why the project isn't completed. Why? Because it was a 6 week project, morons. I've only had one company with management that wanted unit tests written for code. Yet there was no official time dedicated to this process. That 6-week project that would be estimated without unit tests? Still 4 weeks. Huh? What magical world do you live in? Quality requires time. That 6 week project now needs 8-9 weeks. Not 4. Not 5. Find me management that understands this and actually cares about quality instead of impossible deadlines that fit their fantasy plan for the current quarter, and we'll talk. To be clear, I love writing tests. I would always have them if the decisions for project deadlines were left to me. Such decisions are out of my control, so the company gets what they are willing to pay for.

vinceguidry 11y ago
That's not the only reason. Writing tests is hard. Writing tests that are not highly coupled to implementation is hard. That means that every time you change the system, you have one or many test changes to make too. How do you know what to test and what not to test? How many tests do you write? One line of code can, if you think about it exhaustively, require 3 or even more tests. A lot of time you'll write code that facilitates testing. Do you test this code? What happens if the code silently fails and now you don't have proper test coverage of all the code paths said code is supporting? This is particularly true if you are mocking objects. Learning how to test, properly, is almost as hard as learning how to code. My advice is, if what you're doing is boring, like most Rails apps, lean on the library as much as possible, break up anything that goes against the grain into unitary features, and test them each in turn. You don't need to test that ActiveRecord.belongs_to works. It doesn't surprise me that there's developer reticence towards testing. I tried powering through that reticence, believing there's some "magical world" as you put it, where testing actually helps you code faster and more accurately, but I found even myself a TDD apostate, I don't even do it for my own projects anymore.

hn_user2 11y ago

> Not all of the tests, necessarily, but enough to set an example, set the standard, and get the ball rolling. I think you stopped your quote too soon. Writing a couple tests sets a pattern, an example o follow, and demonstrates how important they are because you are willing to take time to do them to begin with. But just giving lip service to the importance of them does not change a culture of untested code. Setting up code coverage reports, test harnesses, a few examples, and then talking about the test metrics shows it's important to management.