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's fundamentally built on sand, inefficient and could do with a root-and-branch overhaul.

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.

There are about 5 different big things I'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:

- 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

Is this the kind of information a software team/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.