
Ask HN: Advice for a non-programmer writing a proposal for a big software change - rusty__
I am a fairly technical person but not a programmer. I am the end user of a large product within our company that I spend a good 5 hours a day using. I think it&#x27;s fundamentally built on sand, inefficient and could do with a root-and-branch overhaul.<p>I have an idea of all of the problems with it and ideas for solutions from a birds eyehigh level. The software team are up for making changes but I need to come up with a good detailed proposal of what direction we need to go in.<p>There are about 5 different big things I&#x27;d like to change so I was going to create a document with those 5 sections and within each section highlighting the areas to be changed, breaking down:<p>- motivation for change
- exact problem as I see it
- proposed solution (from end user perspective)
- pros of making that change as I see them
- cons of making that change as I see them<p>Is this the kind of information a software team&#x2F;product manager could use to go ahead and start planning a project to overhaul this? If not, what better approach could I take to get some momentum on this?
======
mimixco
"Software product overhaul" is a terrifying term because there really is no
such thing. The program you have already might be able to be modified to have
a different user interface (which is what I think you might be asking for), or
it might be entirely replaced by something new.

Unless you have lots of time and money to throw at this, most architect-level
programmers will vote for the first solution, change the UI to make the user
happy. Not a being a programmer yourself, its impossible for you to know if
it's really "built on sand." It might be great under the hood and have a
terrible interface; that's very common.

A real architect would need to weigh-in on the technical deficits that would
be incurred by rewriting or discarding parts of the existing system, including
thinking about all the switching costs of getting everyone over to the new
product. Its possible that your dev team might vote for that, but more likely
that they will put your feature requests in the "feature request bucket" and
get to them as time and tech allow.

------
rawgabbit
If you work at a big company, most likely the software you are using was built
by many teams and heavily customized. The reason why it performs like sand is
that it likely consists of a variety of SOAP or REST services reading and
writing to each other, timing out, erroring out etc. If you want to truly move
the needle you need to educate the dev team what the software’s primary reason
to exist is. Usually this a business process that consists of many steps and
interactions of several teams and users. You need to fight the urge to list
everything that makes you upset about the current system. If you don’t the
devs might spend all their time working on the low hanging fruit and the
system will still be slow and you will become even more frustrated.

------
gulato
I think you're good. The only things I would expand on are:

If you work at a for profit company make sure the "motivation for change" is
framed in a way to satisfy the "profit motive" itch somehow. (save time,
increase sales, whatever)

Ensure your "proposed solution" is articulated in terms of optimizing the
workflow for all users. Try to avoid suggesting things that come down to your
personal preferences. Avoid suggesting a specific technological solution.
(build this in x because I read on HN ... or ... FAANG company uses x and
they're awesome so we should use x)

------
timwaagh
root-and-branch overhaul sounds intimidating. I think it would usually be
better to go with a gradual incremental approach. Still, an overview of
desired changes from a user's perspective will no doubt be useful to whoever
leads the dev team.

