I am a DBA / Report Writer in client support for a software company. Starting in my spare time, I wrote a reporting web application with live reports. The ca 2001 IE only site was horrific. My application eventually became a huge success with clients and was subsequently swallowed by dev. I think it was assumed that I would fail and I was told it would never be part of dev; it will always be a support project. Naturally, after such success, they wanted it. They assumed control, demanded I stop working on improvements, and started giving me tasks to "stabilize" it. I went from architect / designer / sole developer to code monkey. I have zero input anymore. It was fun to do, but that fun has left the building. I want to continue working on it, but my way. My way is why they have it in the first place, so it must work. Now I'm stuck in an AGILE loop. I don't see them giving back control so I want to stop. I'm not a developer or even work in that department. Can they force me to continue?
closed as off-topic by GrandmasterB, Ross Patterson, MichaelT, gnat, ChrisF♦ Feb 13 at 12:30
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – GrandmasterB, Ross Patterson, MichaelT, gnat, ChrisF
A frank discussion about all this with your manager would seem the prudent first step. A good manager will make sure that you get the recognition that you deserve for starting the project and taking it as far as you did. At the same time, your manager may be able to help you in your current situation: he or she might explain to the development team that you have other duties and development and maintenance of the project are now up to them; or, he/she could at least work out a plan whereby you transition away from the project over time.
You should be proud that your project has become so successful that it has outgrown its prior status as your little pet project and is now something that's quite important to the business. At the same time, you need to recognize that projects that are important to the business need to be managed differently than personal projects, and for as long as you do continue working on it you'll have to work according to the same process that's used for other important projects. It's not easy to fun to adapt to a new development process, one which you probably don't fully understand, but you should try to embrace it as a good learning experience. Every company that I know of that does any sort of software development these days is using some version of the "Agile" process. Even if you don't plan to work in software development, at some point in the future you'll likely have to work with a software development project. Direct experience with agile development will be a useful (and marketable) skill.
Well first and foremost if you developed this while getting paid, with company resources, or proprietary inside knowledge then its theirs in most jurisdictions. They will be able to claim ownership of this thing in most jurisdictions. With that goes what direction they want to take it.
The second part of this is that they are not forced to employ you (usually). You don't get to say no unless you don't mind not working there or you own the company. The only course of action you have is to be a part of the meetings where these decisions are made and making your case for feature X or development Y regarding the tool. You don't have zero input because you aren't the sole owner. You just don't make the final call anymore. If you make a convincing case for a feature and there is time to implement it they will likely approve of you developing it as long as any critical defects and stability concerns are already addressed.
It makes sense they want it stabilized. They want to use it and probably move it into a more regular development, release, and support cycle. Especially if they are going to start leaning on it for business operations.
You should take pride in the fact you developed something they want to use and take part in the meetings regarding it.