
Ask HN: How can I influence a change in this development process? - notinreallife
I&#x27;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.<p>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.<p>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.<p>A few comments on QA:
They are non-technical.  Documentation is poor, so the SE&#x27;s need to show QA how to reproduce the bugs and what the expected result is. SE&#x27;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&#x27;s are still asked to be hands on with QA.  Sometimes there will be a bug deep in the architecture that can&#x27;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.<p>Management doesn&#x27;t want to enforce a process because it slows everything down.<p>Honestly, I&#x27;m pretty lost here because I can hardly articulate the intricacies of the entire situation.  Is this common? I&#x27;d really like to get some sage knowledge on what&#x27;s going on here, cause all I see is a painful cycle.
======
spitcode
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
> 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
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
this is some great insight, thanks!

