Ask HN: How can I influence a change in this development process?

5 points by notinreallife 10 years ago | 4 comments

I'm a software engineer at a SaaS company whose product is a large (mostly just complicated) java webapp. The company has seen a good amount of growth over one year and things are starting to explode on the software side of things. Mainly, the fact that the code is fragile spaghetti that has zero unit tests (untestable by design) and there is a lack of software development process.

My issue is that I am feeling pressured from having to handhold QA after I fix a bug. I spend more time doing this than actually writing code.

Here is a typical process to fix a bug in our application: 1. A bug is found 2. The reporter logs a ticket into JIRA often lacking how to reproduce the bug, and what the expected results are. 3. The SE gets assigned the ticket and needs to contact the reporter to find out how to reproduce and figure out what the expected result is. 4. After development, it is up to the SE to show the QA person how to test this new feature or confirm that the bug is fixed.

A few comments on QA: They are non-technical. Documentation is poor, so the SE's need to show QA how to reproduce the bugs and what the expected result is. SE's tried making step-by-step videos on how to test the code change, but that has proven to be a waste of time, as SE's are still asked to be hands on with QA. Sometimes there will be a bug deep in the architecture that can't be reproduced in the front-end. QA is very lost at how to test these. Also, we get a lot of cases, where QA thinks that a test failed, but it turns out that they just had lack of knowledge of the acceptance criteria and prior functionality.

Management doesn't want to enforce a process because it slows everything down.

Honestly, I'm pretty lost here because I can hardly articulate the intricacies of the entire situation. Is this common? I'd really like to get some sage knowledge on what's going on here, cause all I see is a painful cycle.

spitcode 10 years ago |

The key sentence is here: "Management doesn't want to enforce a process because it slows everything down."

Sounds like you answered your own question, resign move on then watch that ship burn, there is a limit to how much change a person could influence.

Sorry I know it is negative to think of it this way but its really hard to find a team that follows a process you enjoy. If you love testing and think that its the right way find a team that does that, don't waste time trying to convince people with a different mind set.

seanwilson 10 years ago |

> The reporter logs a ticket into JIRA often lacking how to reproduce the bug, and what the expected results are

Could you funnel bug reports through a form that requires fields to be filled out before submission? If the report is still seriously lacking, use a canned reply asking for more information and close the report if this isn't given. Also, could you require the bug reporter to write step-by-step what QA must do to replicate?

davismwfl 10 years ago |

Management not wanting to enforce a process because of speed will change, it always does once they see clients leaving because of software quality and feature development slowing down.

The problem is between now and then in addition to hoping the pendulum doesn't swing too far the other direction.

Process doesn't have to slow everything down, my guess is you have one of two types of management or maybe both feeding off each other. A, you have young new founders/management that doesn't have experience with good process so they think all process just gets in the way. B, you have some experienced management that only came from or experienced heavy overbearing development processes.

The fact they have hired any type of QA means they do want improvement, but just are failing to see how to get it there. You will always find that QA requires some hand holding, but in the right situation it shouldn't be taking up the majority of your time.

Depending on what your current role is and what you desire to do and whether you like it there all affects what you can do and how to approach it. If you really love it there but are frustrated you can still try and help things get better. Process can be as simple as starting a daily standup on the QA issues and go over them. But to keep the fear down over the "process", don't make it formal yet, just get people together and say hey lets chat about X and Y and try and save us all some time. And just start doing it, don't ask for permission, don't say it is a process. You can influence how things work by influencing the people doing the work regardless of whom they work for etc. You can start small and do little things like this, and when you start seeing results and say you start getting to code 20% more of the time then celebrate that with an email to the group. By doing that you are telling them wow look at how much more productive I have become, oh yea, its from some changes in how we are working. See what I am getting at? Also, you could try another idea of getting 2-3 of the devs together and agreeing that you will each take one week of the month and handle training QA how to test the resolved defects for that week. It also provides a second pair of eyes on defects and cross trains people into other fixes. Or suggest your management hire a development intern for this type of work.

I am not blowing smoke, I have done this more then once. As a consultant, many times I have been asked to come in and fix things, but I am immediately seen as the outsider and people don't want their processes (or lack thereof) to change etc. So instead you have to be creative in getting the teams to buy into the changes without making it seem like you are creating any bad roadblocks etc. And celebrating little wins is usually really helpful. BTW -- doing it the grassroots way takes a lot longer then having someone in management sponsoring the change or demanding it, but honestly, I think the grassroots team way usually sticks better over time.

notinreallife 10 years ago | |

this is some great insight, thanks!