Build new company software on my own time? Or is that overstepping? [closed]

Question

I started working at this company about a year ago. I work on a team that maintains their web application.

The web application was built about 20 years ago using Java Spring and is extremely outdated with a fair amount of not-so-great code. It even uses XSLT which I think has been outdated since the early 2000s.

I feel like we are on an old wooden boat that has plenty of holes in it and we just keep putting duct-tape over every new hole as it comes up.

To me it's obvious what needs to be done. We need to completely make a new system from the ground up using updated web technology. It is a complicated system that would take time but I think it would be 100% worth it. My idea would be to pay whatever you need to to hire a senior web developer to maybe spend a year or so (or however long it takes) creating the new system. However, I am not in the position to make this call.

So I've come up with the idea of developing a simpler version of the web application (using React and FastAPI) in my free time. It might take me a few months. Then when I am ready to show it off, I can show one of my managers and see what they think. This would help to prove the point that if a somewhat junior developer can do this in a few months, then maybe a team of senior developers can do it in a year. It would also help show the potential of how nice and easy the new system could be.

I'm just worried my managers might feel like I am overstepping and that I am insulting their system (note that one of my coworkers on my team is one of the ones who built the system roughly 20 years ago). What do you guys think?

Answer 1

Probably overstepping. Maybe start with a smaller tool first and see how that goes

I believe this is also a greater undertaking than you imagine. You note that "it is a complicated system".

• How familiar are you with each page and edge cases?
• Is unit/e2e testing currently built in?
  • this takes time
• How familiar is the rest of the team with the new framework?
  • retraining takes time so costs money
• Have you researched framework you want to upgrade to? Is it upgradeable and supported?
  • Will this same process happen again <20 years? Will documentation exist?
• Do you know all the requirements of the project?
  • Not just what is shown, but reasons/requirements from customer
• Does your current project rely on 3rd party tools/software? Is there a compatible library in the updated framework?
  • If not this is something else you need to develop
• Does a customer use/like the current system?
  • new software may have to closely mimic/feel-like the old so retraining, comfort, and satisfaction on customer end doesn't fall

I've worked on a project that I'd consider medium complicated to refactor into modern framework, that was approved from higher ups, with another more senior developer. The number of edge cases, hidden pages, and technology used that you don't even think about is mind boggling. We put 4 months in and in my estimation got 70% completed, base functionality but lots of small details that needed fleshing out.

So if you want to maybe for your own self improvement go ahead, being aware that if you present and they don't like it you also probably can't share it with anyone else as software is probably copyrighted/proprietary and the company may not be pleased if you take their software.

Answer 2

Before you jump in and start implementation, gauge the water.

Since you are not in the position to call the shots, talk to people who can and try to understand their stance.

• If you feel that they also understand the problem / pain points, still unwilling to start the change, listen to their viewpoint and ask question. You'll get to know many other angles aside technical things that needs to be taken care to run an enterprise application.

• If they deny there is a problem, again listen to them.

• Finally, there is a slight chance that they'll actually ask you to propose a solution to the problem, and then, you can go ahead and first present your theory, get it verified, and then officially start working on prototyping (as part of your allocated work).

In short: Listen to what your manager(s) have to say about this.

Answer 3

Extremely risky both politically and financially.

It's not your decision to make, so in some regards, you will no doubt be stepping on someone's toes and possibly jeopardizing your job.

You will also most likely lose a great deal by providing your employer with months worth of work that they won't want to pay you for.

Answer 4

I have done this, and I was a contractor at the time! The development environment was so unfriendly that I simply couldn't bear it, so over a couple of weekends I wrote a better one, and offered it to the company for free, simply to make my job easier for myself. (This was 20 years ago, when such things were possible.)

Responses were mixed :-) Fortunately my manager recognised it as the project-saving move that it was. My co-workers were less enthusiastic -- rocking the boat, too big for my boots, mutter grumble mutter. But looking back, I see it as a turning point in my career.

So what I say is, go for it -- you have nothing to lose but your mediocrity.