Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
We are a start-up, with a few (14) clients using our products. These products were developed in a closed 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.
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
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.
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.
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.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Are having APIs for the sake of QA testing a good or bad idea?
We're developing an application from scratch and we've been creating backdoor APIs to ease the jobs for the QAs. These backdoors do things many things like change the date of the server to emulate progression of time etc. I'm quite mixed on this. The number of these backdoors almost rival the real APIs that'll be used in Production.
Is this the recommended approach? The obvious benefit for this is that it makes the lives of the QA must easier. I can see many disadvantages with this also like maintaining the functionality of these test APIs, ensuring that these backdoor APIs are not exposed in production.
If others have used this approach, what are some good means to ensure that these APIs aren't exposed in production?
For those who are against this approach, are there alternatives to making the work for QA easier?
Thanks
If it's not causing QA to miss issues, it's a good thing to do; if you can make their job easier without costs in the future, do it.
However, normally anytime you test one API but use another API, you're not actually testing the real API that's going into production. If QA has a hack around the normal API, they should also be testing the difference between the hack and the real world.
In this case, it sounds like they have helper methods to modify the state, to enable testing. If there's not a good way to do this otherwise, what they're doing might be pretty darn reasonable... or, at the very least, there may be better ways to spend your time improving things.
But overall; is it regularly (repeatedly) causing them to miss bugs they should have caught?
What build system are you using?
For any software that has any time/scheduling logic, I think it's pretty essential to add a class called SystemClock with a method called 'currentTime().'
In our Android project, we inject the starting time from a Gradle variable, and then we can be sure that there is no way the code can get into production with shifted time (because the variable is defined for the debug build only).
For our iOS release, we were able to use an Extension. That's really a great way to do it because it's only compiled into the test scope. Then it replaces the getCurrentTime method with the shifted one.
The other option you have in the Java world is Aspects. They can be handy for doing mixins in a test build that are not there in production.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
While looking for the job, i have attended some job interviews at companies, that work at financial sphere. Every company uses Spring Framework as main framework for development. And almost everywhere I was told 'We need proved and stable technologies, that is why we use Spring.'
I would like to know, as I can't understand, why Spring is more popular and 'safer', than Java EE (for example, Spring MVC is used more, than JSF, while both provide almost the same functionality)?
How it is possible, that native Java EE functionalities are less stable, than third-libraries?
Some reasons:
Spring was already there: J2EE was ugly (no Dependency Injection, no conversion over configuration and lot of scares from EJB2, ouch). Java EE "stole" all good ideas from Spring, and it is in fact lighter and easier than previous versions. But now, everybody already uses Spring. It means a lot of production code, lot of well tested products and so on. In the end, why do people in UK/USA use English units? (There is a huge cost to change)
Spring is lighter: You do not need a heavy Java EE application server, you can deploy your application in a web container such as Tomcat.
Spring offers a ton of features which are not available as Java EE standards, such as Spring Batch or Spring Integration. You can use Spring features with Java EE standards, but it should be supposed Spring works better with Spring, shouldn't it?
Spring Aspect-oriented programming is more flexible and power that Java EE interceptors. You can use third-party AOP with Java EE but you can have this out-of-the-box from Spring.
Spring moves faster. Spring can release often and faster because it is no standard and only one vendor. So, it is not required JCP ballots, approvals, etc. The reaction to market requirements is much faster. Some current examples: cloud, mobile, social computing.
Ironically, I have "got" a lot ideas from:
http://www.kai-waehner.de/blog/2011/11/21/why-i-will-use-java-ee-jee-and-not-j2ee-instead-of-spring-in-new-enterprise-java-projects-in-2012/
While looking for the job, I have attended some job interviews at
companies, that work at financial sphere. Every company uses Spring
Framework as main framework for development. And almost everywhere I
was told 'We need proved and stable technologies, that is why we use
Spring.'
I work in financial domain since several years - so I can speak from my experience.
Many financial service providers I know had a major upgrade to their enterprise software stack at around 2006-2008, at a time when the disillusion about EJBs were at its peak after several unmaintainable and poorly written EJB projects. So in-order to upgrade their system and also to attract developers, they began to re-implement their stuffs in Spring and Hibernate, also it was a logical step for them to start new projects in the state of the art frameworks (which at that time were Spring, Hibernate and Wicket)
But since then financial crisis broke out and not many financial service companies think of investing that much money in new development unless it is very critical. Most do not care whether Java EE 6 or 7 was launched and some of the old arguments do not hold good anymore or so.
So they would like to believe that what they have is safer, faster etc (which may or may not be true)
One thing that makes Spring attractive to developers, especially at big organizations like financial companies, is that it lets them take more control over their middleware. With pure Java EE, developers are at the mercy of an operations group that has very different goals than they have. In many cases operations wants to avoid messing with anything that works, every upgrade is a chance for things to go wrong, and it's not like they're the ones who see the benefits from upgrades, so that makes their choices very conservative. That can mean developers get stuck with obsolete versions of an application server, and if a problem comes up the developers have to work with the vendor's technical support (so you have to convince the vendor you have a problem and reproduce it under the conditions they specify), then coordinate with operations to implement the fix (which of course means justifying your request to an organization with different priorities from you). Developers like to minimize this kind of thing whenever possible.
Having Spring in the application gives the developers more freedom to update more of their infrastructure on their own schedule.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
My company is about to start building the back-end for one of our new products. The idea is to build a layer that produces resources for every upper layer product (web site, mobile web site, mobile application), also, a significant part of it will be made available as an API for third party developers. You know, the typical start-up scenario.
We were planning on building our backend using Java Servlet Technology so our architecture was going to be dependant on Java, so the question is: What are the implications of Oracle scaring away open-source-aware developers and companies like mine?
Should I try to find an alternative to Java? Are you trying to move away from Java?
This question is not about technical issues with Java platform, but with legal implications of Oracle draconian intentions (my subjective point of view).
EDIT: Of course this question is subjective and argumentative, that's the kind of answer I want: opinions, and opinions are subjective and argumentative.
I suspect that Java will remain a strong back=end platform for a long time. Oracle, among other things, doesn't want to kill the golden goose. In addition, there are too many good back-end components based on Java, from Tomcat to messaging, to hibernate and spring, to groovy and grails; the market won't let them disappear for a long time.
Technically, Java is well suited for complicated back ends and large-scale problems; if you're building something simple and lightweight, using a framework like Rails along with an open-source database is often plenty.
Groovy and grails are a nice bridge from the lightweight approach of Rails to the full Java world, although groovy can be a little, um, peculiar sometimes.
We were planning on building our
backend using Java Servlet Technology
so our architecture was going to be
dependant on Java, so the question is:
What are the implications of Oracle scaring away open-source-aware
developers and companies like mine?
Are they? Last time I checked JBoss and Spring were going strong. Scala is being considered as a strong alternative for replacing Java (or it will shape the next best language for app/system development on the JVM.)
What exactly are you referring to here? I don't follow. Now, if you are going in direct competition to Oracle and their stack (and all their integrated solutions, like Oracle Financials), then maybe you might have something to worry about.
Or if you are (or intend on) doing something that violate (or can be interpreted as a violation in a court of law) the Java license agreements, then you might have to worry about Oracle (because it has the teeth to pursue them, which Sun did have.)
So, you need to be a bit more pragmatic and objective and define clearly what exactly your product role will be with respect to Oracle products. Based on that, you have then to decide whether investing on the JVM is a good decision or not.
Should I try to find an alternative to
Java?
Depends on what you are trying to achieve. A question like that is too broad and open ended to be answered in a meaningful manner.
Are you trying to move away from Java?
From the point of view of curiosity and diversifying my skills, yes. But were I in charge of developing a back-end product, I'd use the JVM. I might try to use Java and leverage from the 15 years of collective knowledge on the platform. Or I'd try Scala. But I would stick to the JVM.
Oracle or no Oracle, for these type of things, the JVM is the superior choice in terms of stability, scalability and wealth of knowledge. Erlang VM might be better from a technical point of view, but you would be hard press to build a talented team compared to building a similar one for the JVM.
Found an article discussing the future of Java, dated 05.03.10.
Okay, conclusion from the same link,
While the wheeling and dealing of the
corporate world rarely affect
developer communities as a whole, the
Oracle acquisition of Sun will have
far-reaching affects for years to
come. And while the profitability of
individual Oracle products may not
concern you, as a developer, the most
interesting points remain to be the:
- Combination of HotSpot and JRockit into an uber-JVM
- Unification of the Java SE and Java ME APIs
- Increased investment in JavaFX onto more platforms
- Continued integration of dynamic languages into the JVM.
I would recommend Java as a back end platform, I am currently employed with a company that specializes in software business solutions for companies, and nearly all of our work is revolved around using Java in the back end.
I am not sure if your back end is going to be web driven or not. I would say take a look at using the Spring Framework with Hibernate Database support. Spring has excellent support for using Hibernate and so many other tools and thats why I am a supporter of it. Unlike some other frameworks that limit you to using only certain tools, Spring does a great job of allowing you to integrate many different libraries, tools and frameworks with it. This is good because as we know too well, technology is always changing and something that is popular now, may need to be changed in the future.
Java as a back end solution will require a little more work in the beginning as oppose to lightweight approaches like Rails, but once you get everything setup(database,build files,etc) then it is off to the races.
If you end up taking the Java route, look into using Maven for building. Ant is also good, just a little more work to setup.
... did you rule out any particular technologies and for what reasons? Is .Net an option?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
This question could bring a lot of opinions to the table, but what I will like to get is a set of measures that will help me and my company determine the end of life of a product that we sell.
We sell a CMS system, with this system we create a few sub-products
Websites
Proposal Creator
Marketing Campaign Tracker
We are ready to start our road planning (for 2010 and 2011) and we are trying to figure when will be the end of the life of our application. Some of you might think that a very well architected application (I don't think our application is well architected) does not need to have an end of life, but this app that we are using goes back at least 6-7 years and has almost no documentation (real life). At this moment only ONE person knows how to change core functionality (scary).
Please advice,
Geo
Thanks to All! I really appreciate your comments, opinions and thoughts on this topic.
I will address a few of the post back questions in the list below
There is one developer that is able to maintain the core functionality of our product. (only and only one)
There are two developers that are able to increase functionality to a certain point. Both developers are constrained by the limitations of the core product, and they both have to work within those limits.
A very important note. The product that we are considering to put to end-of-life is for the most part being built by a contractor. The contractor is the only developer able to maintain the core functionality. We only develop on top of the contractor framework.
I will keep adding answers while I read you all responses.
Since application is very well architected you may not want to retire it and loose all investment you have made to date.
Here are my suggestions:
Have a junior developer join this
current developer.
Dump most of future updates on junior
developer (with assistance from sr.
developer)
Ask junior developer to do the
documentation of his work
Ask Sr. developer to review
documentation
Over period of time, you have another person who can support this application and it will be documented as well. Now you won't need to kill your own very well architected application with your own hands.
.
Extending this solution with Jefferey suggestion below("Sometimes rewriting is a good investment.")
If you still want to drop current application and re-write it, you still need to document existing system and create requirements for new system based off it.
Using documentation of current and proposed system, you may want to see if you can incrementally module by module upgrade (re-write) components. This is possible if application is very well architected.
As per your (Geo) comments
Geo's organization has custom third-party (with one and only one contract developer) CMS application that implements below business requirements and is paying licensing fee for support and use of his code.
Business requirements for CMS
Websites
Proposal Creator
Marketing Campaign Tracker
Here are my suggestions
Create module by module detailed use
case document for this project. Your
developer can do this or would be
ideal to have a seperate business
analyst for same.
Hire a Sr. Developer to evaluate if
open source CMS can handle all or
most of your requirements (e.g.
Joomla, Drupal, etc.).
Most important thing here would be
ability to migrate your existing data
to new system. You may need help from
your existing contract developer to
do this.
You may have to update business
process or workflow to use new
system.
Modules that cannot be implemented
using open source CMS may be required
to be implemented using custom
website.
Much of it also depends on your business relation with existing contract developer and license agreement. What you are facing is a vendor lock in scenario. You may want to further research on solutions to eliminate this vendor lock in situation.
This is just my opinion, but if this is a product that you are selling, then it all boils down to business prospects. If the product doesn't sell, then drop it. If the product has a future, then invest in it, and make it the best software you can by refactoring, rewriting, or whatever you have to do. If you have loyal customers or a strong brand, then that's worth protecting.
Sometimes rewriting the whole thing in another technology is a good investment, if the current software has a successful design that can be copied, has a strong brand, and if it can be done right.
The application reached end of life the moment it shipped without any sort of documentation. Begin development now, and you might want to consider replacing the person who knows the original system. If they've gone 6/7 years without creating any sort of documentation whatsoever, they're not someone you'll want in your company.
The only kind of documentation which will extend your system's life are things which stay consistent as the system changes in its lifetime, like test suites, self-diagnostic tools, code comments, declarative contracts like interfcaces, and automatically generated documentation.
Other manually managed documentation artifacts, like manuals, developer guides, architecture documents, data formats tend to become out of date in proportion to the amount of documentation. I would not count these as factors which increase your application life expectancy unless you have already factored in the cost of maintaining them.
If you can't "afford" developer redundancy to maintain the application reliably, there's no way you can afford to keep the documentation up to date. Lack of documentation is really a technical debt you've decided, perhaps unconsciously, to take on. If a longer lifecycle is a requirement, then the cost of that has to factor into meeting that requirement.
To make a long story short: I am in a comparable situation.
As long this application is something like a cashcow, but the company can't afford (or intend) to develop of a new application, it will not die before customers decide to buy a fresher system.
Rewriting without (documented) requirements is almost impossible.
At least the experience of specialized departments, should be documented in a way that is useful for further developments.
If you have to maintain this application, you should introduce interfaces between modules,
to reduce overall complexity. So old modules no matter how messie they are, don't care if you have to plugin new functionality.
Even if it is very well designed and functioning, the fact that it has no documentation and depends on one person for its life, means the product has very well entered an unmaintainable state. This is not a good sign. I would agree that the product is long past "End of life"
These are the kind of things I might consider when deciding if a system might be going "end-of-life":
Is the functionality that this system provides available to end-users in a cheaper, more reliable or easier to use form? If not now, then when is this likely? Is this product therefore viable in the longer term?
Is this written in a technology that customers would steer away from as it would be awkward to interface into their products, or require them to run "obsolete" platforms? Would it give a potential customer the impression that your company is significantly behind the times e.g. VB6 is probably just still OK, even in 2010, but requiring Win16 compatibility probably isn't.
Can you hire good people that know the underlying technical platform at a reasonable cost? On older tech, it might be that there are lots of people that know the platform but see it as a dead-end and will ask for a premium salary if their career is going to languish in the doldrums whilst they work on it.
If it matters to you, is the development platform still supported by the vendor? Are you going to be constrained on what hardware or OS you can run it on if the vendor is no longer updating it? Likewise, are there security holes in the platform that may need to be updated? Even niche Open Source products can suffer from this. Once a product goes out of favour and core developers move onto fresh projects, it can be difficult to get fixes done by the community.
If it is supported, are the vendors charging you a premium for supporting an older platform? If not now, then how long before they do?
How difficult is it to integrate new technologies into it to take advantage of current trends that offer enriched functionality to end-users to keep you competitive? Do you care about this? It may not matter if you're essentially running a closed system.
How difficult is it to release functional changes to it without extensive "shotgun" changes that ripple across the whole system? This comes back to how modular the system was designed to be in the first place. If you're no worse that your competitors in getting features to market then you're probably OK.
What would be the cost of re-writing the system? How does this compare to how much cheaper it would be to maintain or increase of sale revenue? It might not be economically feasible to do a whole re-write. If the development platform is sound then you could just try more of a refactoring approach. This is where having a good test-suite and documentation helps.
I went through a similiar process. We had a web app that had run for almost 8 years. In that time a lot of maintenance was done, extending it in ways we hadn't envisioned. However, the core was good and it was still able to be stretched.
What pushed us over was the maintenance cost. Finding people with the right skill set was easy 8 years ago. Today, no one wants to work in those environments; not even us :)
After analysis, we knew we could replace it within 12 months with identical functionality AND that this time spent would pay off quickly.
So, we used screen shots as our functional requirements, revamped the look and feel, and were even able to deliver increased functionality. We also looked at usage data to identify parts that were either rarely or never used and trimmed those, and focused more attention on the parts that were used.
Ultimately, we were successful. In part because everyone on the team was well versed in the new technology so there was little need for learning. Other contributing factors included a well thought out design. I think we spent 3 months just in design before writing anything.
The final factor was that our app is modular. So we were able to chunk it out in sizes small enough to have a combination of short delivery schedules with a downtime / analysis period between each deliverable. This ensured we were on the right path at every stage.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
We are developing a Java EE application backed by any database of customer choice.
We will sell to customers based on per user license price. How do I make sure, the application is getting used as per our conditions, i.e., not easily hackable? Are there any tutorials available?
Bill Karwin's answer was the most useful of the answers from the question mentioned in the comments. Assuming that you will go ahead with a "protection" scheme, try to do the bare minimum. Anything else tends to frustrate users immensely and leads to lower repeat business and/or an increased desire to hack around your frustrating system.
From your question, it's tough to tell if each user will install the application. If so, you probably just need to require a license code that they must contact you in some way to get. If it's a client-server thing, then your options are a lot more limited; in fact, I can't think of a single solution I've ever designed in my head or come across in practice that isn't massively frustrating. You could probably do a license code solution here, too, except the license code would somehow carry a payload that indicated the number of users they paid for and then disallow the creation/use of users in excess of that number. At that point, though, you're really walking that frustration line I mentioned.
If you can obfuscate - this is the way to go for a start. But it could be painful if you use inversion of control frameworks (e.g. spring). I heard that it's possible to obfuscate spring context as well, never tried it though. Also (just guessing) there could be some surprises with reflections, dynamic proxies and such. As to the licensing, I can suggest using TrueLicense. It has very flexible means of handling various aspects of protection as well as free trial periods out of the box. Works very well and has great documentation.
Do clients pay for support of this application? If so, there is a chance that support is a bigger pay-off than the licensing of the application itself. If so, you may consider not locking down the application, but rather, choosing to only provide support for authentic copies of the software (unmodified copies proved via checksums and the such). Many businesses licensing this software would be more inclined to avoid any modifications (even though the chance of them wanting to actually do this is probably tiny) in order to not jeopardize their support.
FYI: This is how Oracle tends to operate with their e-Business Suite. You can modify pretty much any component you want. Good luck on getting support, though!
Look at how Atlassian sells their products. I believe this is an approach that works very well, and probably would for you too. Note: There should be added value in subscribing to updates!