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!
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 6 years ago.
Improve this question
First of all, I love Python, and I currently use it for most stuff. However, as a PhD student, I mostly implement prototypes for testing and evaluating ideas. This also includes that I'm usually the only one coding, and that -- while I certainly try to write half-way efficient code -- performance is not a primary issue. And for quick prototyping, Python is for me just neat.
Now I consider to go with some of my stuff more "serious", i.e., to bring it into a productive environment, make it better maintainable, and maybe more efficient. So I wonder if it's worthy to rewrite my code to, say, Java (with which I'm also reasonably familiar). I know that Python is not slow, but things like Java's static typing including seems to make it less prone to errors on a larger scale, particularly when different people work on the same project.
It's only worth it if it solves a real problem, note, that problem could be
I want to learn something better
I need it to go faster to reduce power requirements in my colo.
I need to hire more people and the talent pool for [insert language here]
is too small.
Insert innumerable real problems here.
Python and Java are both suitable for production. Write it in whatever makes it easiest to solve the problems you and or your team are facing and if you want to preempt some problems make sure you've done your homework. Plenty of projects have died because they chose C/C++ believing performance was going to be a major factor without thinking about the extra effort involved in using these language well.
You mentioned maintainability. You're likely to require more code to rewrite it in Java and there's a direct correlation between Bugs and LOC. It's up for debate which one is easier to maintain. I'm sure both camps believe theirs is.
Of the two which one do you enjoy coding with the most?
The crucial question is this one: "Java's static typing including seems to make it less prone to errors on a larger scale". The crucial word here is "seems." Sure, Java will help you catch this one particular type of error. But how important is that, and what do you have to pay for it? The overhead imposed by Java's type system means that you have to write more lines of code, which means reduced productivity. I've used both and I have no doubt that I'm more productive in Python. I have found that type-related bugs in Python are generally easy to find and fix. Keep in mind that in a professional environment you're not going to ship code without testing it pretty carefully. The bottom line for a programming environment is productivity - usable functionality per unit of effort, not the number of bugs you found and fixed during development.
My advice: if you have a working project written in Python, don't rewrite it unless you're certain there's a benefit.
Java is inherently object oriented. Alternatively python is procedural.
As far as the ability of the language to handle large projects you can make do with either.
As far as producing more usable products I would recommend java script as opposed to java because of its viability in the browser. By embedding your js in a publicly hosted website you allow people with no coding knowledge to run your project seamlessly in the browser.
Further more all the GUI design features of HTML are available at your disposal.
That said any language has it's ups and downs and anything I've said here is simply my perception.
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 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 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.
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 5 years ago.
Improve this question
I'm thinking about developing a web app to visualize the agile wall. The reason is that the project I'm working in has multiple distributed teams, so it is very difficult to share the information on the agile wall across the teams. I know some tools like JIRA do have agile wall functionality built in, what I want to have is a dedicated agile wall web app which could potentially integrate with those popular project management systems.
Does this idea sound sensible and interesting to you? Please let me know if you get better idea about sharing the agile wall across distributed teams.
Thanks.
John
Have you looked at Mingle from ThoughtWorks?
I haven't looked at it recently, but I'd expect it to be open to integration with other systems.
Even if you end up wanting to write your own, you should look at Mingle to see what a similar system looks like.
I'm not sure how well the card wall translates to a small screen. I've seen one similar implementation of something like this (www.cardmeeting.com) that I was not impressed with. One of the drawbacks to it is that the cards are unreadable until you click on them. That being the case, the tools used by most commercial vendors to capture stories at least the advantage that you can immediately see the titles on the stories even if they don't implement the wall format.
Another concern that I have is trying to take a passive information radiator and insert it into an active presentation medium. The wall format works partly (or even mainly, I haven't really looked at the research closely) because it's highly visible but not intrusive. Whenever you see it you get an immediate snapshot of the current state of the project. Translated into a web browser, you lose this aspect. It's not clear to me that in an active medium, where users need to navigate to information rather than simply absorb it, if the wall is still the right tool.
Take a look at Simple-Kanban. All done in a single HTML file.
Before you start implementing your own tool, take a look at:
http://www.userstories.com/products
I'm sure you can choose something appropriate :-)
Guess which one is ours...
Regards,
Marcin