I think it's perfectly fine to work on a project with coworkers "just for fun" outside work as long as we're not on company time, and we're not using company resources.
But our situation isn't playful as mentioned above. We are facing a situation where our manager is adamant about not using frameworks, technology, and other modern development practices they do not understand, even when their requirements are easily and directly addressed by the newer tools. We are forced to write hacks to get the older technology to make things look and operate like a modern product, and it is taking a very long time to develop in such a manner. Also, our manager insists on using the same older technology for any future projects (which are more demanding of modern technology in nature) for the foreseeable future. Our manager does get uncomfortable and does get angry when we suggest that a feature in a newer framework easily addresses a problem we have in our current project. They even told us that there is no proof that the newer technologies and frameworks are faster to develop than legacy ones, which inspires us to pull this feat.
So instead of trying to win the manager to implement newer technology and practices in the company's current projects, we decided to work on a outside project, including logging the time it takes us to discuss, develop, test, and document the product and process. Yes, we intend to submit all of our documentation and demonstrate the working product to our manager in the near future, with the main intent of proving easier development and more importantly, far less time to develop and deploy. So we'll accept the current requirements for the current project, but are fighting for modern development for future projects. To be clear, we will not develop the outside project under company time; we will develop it in our spare time at home, including our communications. We are willing not to get paid for this side project. We are also willing for the company to ultimately own it should they accept it.
It does seem like our ultimate goal is to gloat at our manager. That is far from the case. We just want to deliver quicker and more importantly, more effectively. We just see our newer technology proposals as beneficial for the company as well as a better experience for everyone.
We realize that pulling this is risky and probably offensive and disrespectful. But in the past, there were programming and development practices that were previously "banned" like inheritance and creating/implementing interfaces (because those confused them but our main language has those features), meaningful variable naming (because it took too much time to think of and type the appropriate names), and source control (because it required a learning curve that would take time off current development). We have managed to get the manager to embrace those (by showing the amount of duplicate code we no longer have to write, by asking the manager what they meant when they wrote variables like
temp2, etc. and they couldn't tell us right off what those meant, how quickly we can roll back the project to a previous successful state), and so we may have a shot at getting the manager to adopt/accept other tools and frameworks, again, for the appropriate future projects as each project deems necessary. Some future projects are basic enough that the older technology will suffice.
But we somehow feel that we could be backstabbing or disloyal for pulling this feat, and at demo time, it feels like defiance. What other approaches may we take in our quest to win this battle?
We request that you do not provide the following two suggestions, as we've seen those in enough posts:
- That we have no business being in software development if we are unable or unwilling to develop with such debilitating restrictions, then work in another field.
- Leave the company and apply to another or found our own software company. (This is our last resort, and as much as possible, we don't want to choose this option).
We would appreciate your feedback.
Thank you very much for all of your input regarding this. A vast majority of you have advised against what looks and feels, even to us, controversial. We realize that there are interpersonal and financial implications with our plan, and that our chances of overall success are practically <= 0%, despite being able to claim some technological victory.
We still plan to work on projects outside work, but we have changed our approach to be more on the defensive side, and our primary purpose no longer to prove ourselves (which unfortunately also reads prove the manager wrong), but to build our knowledge and experience. This way, we are ready in case the manager accepts newer versions of our framework, other frameworks, tools, and practices in the (hopefully) near future, or we are better equipped/more marketable in the unfortunate event that we may need to seek other employment.