4 ms·

Ask HN: Broken tests, huge (250 commit) pull requests, growing team, what to do?

• trcollinson 11y ago
  You have no contact information :) just so you know. At any rate, these problems seems huge usually but often if a person or set of people can focus on them, they can be knocked down rather quickly. Then it doesn't take a whole lot of time to keep the project on rails, so to speak. Each situation is different but I would be more than glad to speak with you more. It is usually an balance between trying to see the whole project and yet not trying to bite off more than you can chew as you fix technical debt. Small, iterative changes add up very quickly.
• runawaybottle 11y ago
  This may or may not be relevant. If it seems like only you care, there's a possibility you care too much. That could be a good or bad thing depending on a lot of factors. Take a step back, and really determine if you are not needlessly projecting personal problems onto a job. Are you getting paid? Is the business making money? Are you getting proper feedback? Do you feel you have influence? Is it really you against everyone? What's important to you really?
  • pm24601 11y ago
    I second this. Focus on understanding the VALUES of the other people. If you feel the tests are important you have to get the others to see how the tests are valuable in a way that they value. "Fast feature delivery" -- show how tests can deliver faster feature delivery ( it may be that the current tests actually slow down feature delivery ) "Late nights/Missed dates with SO" -- show how tests can reduce late nights and get the person home. "Reliable schedule", etc...
• pm24601 11y ago
  If no one cares, no consultant will be hired or respected. The team is saying that this is not a critical item for them. If I may suggest, 1. Do all the tests need to be fixed? (i.e. how valuable are those particular tests?) 2. Can some of the broken tests be turned off? 3. Seek to understand the priorities of the others and understand how to make tests more relevant to them. 4. Seek to understand which tests deliver the most critical value. For example, 1. "Mark" complains about working late on reproducing a bug. Can you help him create a test case that reproduces his bug reliably so that he can test a fix faster? 2. "Jessie" complains that tests are hard to maintain and she has too many other things to worry about fixing tests. Ask "Jessie" to help make ONE test easier to maintain. 3. "Jane" complains that the tests just test trivial functions and if they break the tests are broken, not the actual code. Turn off trivial tests. 4. "John" complains that "all" the tests are "always" broken. Turn off the broken tests so that people get used to seeing "green" so that "not-green" becomes unusual. 5. The CEO wants features fast. Work on understanding how to communicate the idea of consistent forward code velocity. You have to use their language to communicate to them. If the CEO is worried about a funding target in the next 2 months, it is difficult for them to care about something that only delivers value in 3 months. (I like testing and I would not care myself about tests in this case) A failure to communicate != Stupid. A failure to communicate == not understanding the other party's priorities. A failure to communicate == not understanding the other party's language. -------------------------- Lastly, tests only fit in well if there is a DEVELOPMENT PROCESS that values testing. Does the company have any process? (ie. Scrum, Agile, Kanban?) If the company has no process, then any talk about tests is the wrong conversation.
• MalcolmDiggs 11y ago
  Oy vey. I'm curious, is there a leadership vacuum (no CTO/VP Eng on staff), or is that the people in those roles aren't doing their jobs?
• wkoszek 11y ago
  You should sit with them and explain what it really means to your business what they're doing. If it doesn't help, you should probably hire a senior person to teach the rest of your team what software engineering is all about. I don't think the consultant will help you, since from what you describe, it's an attitude problem and lack of the global point of view issue in your team. e.g.: once the consultant leaves you with $5k+ bill, they'll likely come back to their practices. Bear in mind: if it's a startup, sometimes it's messy and it may get some time before people will come back to the "usual" state.
• plet 11y ago
  A : "we're delivering features" B : Would you rather deliver features or make sure the platform that you're working on stays running ? For the product/project itself, setup a continuous delivery pipeline. Allow (if possible) one pull request at a time. Let integration/load/benchmark tests prove that its not breaking anything. If the tests are broken, whoever breaks them gets to fix them. They're not in the team anymore? no problem. Whoever needs to push a change, need to make sure the pipeline is working. Growing team needs direction. Set up tenants / guidelines / vision. Assign product owners that are responsible to customers/stakeholders. Also, figure out why nobody cares. Is it lack of knowledge / best practices? Is it lack of interest? Is it not-my-job phenomenon ?
• japhyr 11y ago
  What's your deployment process if the master branch is broken, and your team is still delivering features?
• yarper 11y ago
  As someone who's been there - my advice is to find something new as soon as possible. It's all very well trying to be their technical saviour but in the end you can't fix it all. Typically if the tech leadership is broken, the company leadership is also broken.
• benzesandbetter 11y ago
  If you're already tried to communicate these concerns to the leadership in your company, and are not getting support, your best course of action may be to move to a new company where good development and deployment processes are given the respect they deserve.