How to determine a development strategy change from the middle management?

Question

We are a start-up, with a few (14) clients using our products. These products were developed in a close source web development framework only maintained by one developer on the core.

Basically the framework server is required to be able to run any application built in it. So there is no code, in our layer of the application. Think of it as a CMS that allow us to develop in a proprietary language of the framework server itself.

This framework is built on Java, and is closed source. It has a layer of plugins that need to use a proprietary IDE to build them.

• There is at this moment only 3 total developers in the company mother of this framework, one that is able to code on the framework itself, and 2 that are able to code on the IDE to build plugins. We are the only company holding paying the salaries of 2 of the 3 developers, the 3rd is the owner.
• At this moment we don't know if there is documentation for the framework level.
• We know there is no documentation for the plugin layer.

The ONLY reason keeping us developing in this framework is that we already have invested in it, and changing will cost us.

I am in the middle technology management, and I have been advising my IT Director/President of some changes, but apparently I am not getting through. I am advising to start developing new components in another framework (ASP.NET MVC, Symfony, SPRING MVC) with our own team of developers, and this components to integrate 100% with our old application, until we get comfortable to a point of porting the old applications from the old framework to the new one.

Either way there could be many variations of this plan. Any advice from knowledge of SO.

---

As an alternate question: Why would you build a business on a close web development framework that only has one developer and no documentation?

---

Last Comment: I think that probably Bruce is right. My upper management team is more concern about continuing to sell and support our current product than to the risk that constituted continuing with it. Probably when we grow from 14 clients to 30 clients they will see the lack of scalability that we own, and take some other actions but for now. I think this battle is all done until 2011. Thanks for your input.

Answer 1

Scrap it and migrate as fast as you can because you're only throwing good money after bad. This is what is known as the Sunk Cost Fallacy

Answer 2

From what you've said, the major road block to changing software is that the owner developed your current undocumented code.

Focus on bringing the owner on board with you. Once the owner votes for changing to new code, you'll be able to get something done, until then you're probably stuck with band-aids.

Answer 3

Management in a small company is concerned about staying in business and satisfying customers. If the current architecture is supporting that, then the managers will be happy and resistant to change. If business is shaky, they may not have the resources (cash) to support investing in the time and tools for developing a new framework.

If the business is doing well enough to support investing resources in the new framework, it is up to you to make the case that the Return on Investment (ROI) will be worth the investment. They can then decide if they have enough time and cash to pay for the change.

The cases for changing would be: Measurably improved development efficiency. Measurably improved quality. Noticeably increased functionality. Risks associated with staying with the current platform.

Answer 4

Looking at the current development on the market, the only reason is a bad strategy.

You may try to open the product on a dual-license base, but if there is no documentation, it is unlikely that developers from outside will jump on it (although maybe the IDE could help a little bit at that end).

Stipulating the change could be based on a risk vs. opportunities assessment.

From the scenario you describe, I think that a central factor to be considered seriously is Human Resources:

• What happens if people come and leave?
• How likely can growth be handled?

Also seriously consider the knowledge part of the picture: as an organization you need to manage a better equilibrium between tacit and explicit knowledge.

Maybe try to determine the barriers for change (individual and organizational) i.e.:

• ability (can, to be aware of),
• readiness for change (want, should),
• shared reality,
• system thinking

analyze them and integrate results to support a more informed decision making process.