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.
Related
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.
I'm working for small company, which operates in the automation industry.
The boss hired me because he wants to sell/give some desktop applications to his
current costumers.
He imposes me to use the Netbeans Platform (a generic desktop application framework).
A software engineer friend of his advised him to choose this framework.
At the moment I created 3 desktop applications with Netbeans Platform.
I like Netbeans Platfom. I really take advantage of modularity, Window System and Lookup.
Unfortunately I'm frustrated to known that I can do the same works with Python and PyQt in a fraction of time.
I've already illustrated to my boss the main advantages of Python, but he doesn't like the
idea to use a language that he never heared of it.
I'm the only programmer who codes desktop applications. And except the framework imposition, I'm free to use whatever I want.
I'm looking for good motivations to convince him to leave Netbeans Platform for Python/PyQt.
P.S: My english is bad, sorry.
If your selling skills are not working in discussion format I highly suggest that you document it. Some managers/bosses really respond well to this.
Make a matrix of all the metrics that you yourself use to grade the two frameworks (I leave the level of objectivity to you there: for example if objective it should analyze the cost of transition and the loss of institutional experience; but it might not be high).
Finally, send it by e-mail and viola you have:
made a report/analysis of the situation providing options for improvement
this shows that you are thinking towards future and that you show initiative
EDIT:
You can also ask your boss to show your analysis to his friend if he trust his friend that much, but ask for a written counter-analysis so that you can address the critique.
It is a good thing to do it openly and document the decision process well, since ultimately, if your suggestion is accepted, you will share responsibility for the decision.
The problem is that development time is usually nothing compared to maintenance. Who cares if it takes two days instead of four if the app has a 1-5 year lifetime?
You'll have to convince him that if you get hit by a truck or leave the company (perhaps to work for somebody who uses Python exclusively) that he won't be left in the lurch with a bunch of applications that nobody else knows and can't maintain or upgrade.
The basic problem here is that your non-technical boss is getting conflicting advice from you and from the friend who advised him in the first place. If you want him to take your advice seriously you need to prove that your advice is likely to be trustworthy. And that will only come with taking the lead and being successful with significant projects in the company. Right now, you haven't earned his confidence.
The other thing to consider is how your preferences mesh with the company's objectives. For instance, you want to be able to write code fast. But the boss / the company needs code that is going to be reliable and maintainable ... if you decide to take another position. He doesn't want to be left in the awkward situation where the company is contractually committed to deliver code that doesn't really work properly, and the only person who understands it has left.
First, results speak for themselves: if you can piece together another version of one of your applications in pyqt, and tell him how long it took, it might be motivation enough.
Or, next time you're starting a project, you could prototype four or five different versions of the interface in pyqt in the morning, ask his feedback after lunch, and then say, "if I keep going on these, it'll be done in two days; if I redo this in netbeans, it'll be done in four."
And as for the "never heard of it", feel free to point out that Google uses python extensively, and even hired many of the python developers.
Some people will tell you to try to convince your boss verbally. Others will tell you to document the time savings you think you can make. My opinion is that you just go ahead and do it. Do it in your own time if you strongly believe its in your best interests.
I'm yet to meet a software manager who turned down a working piece of software when it comes in on time and under budget. This is by far the best method of persuasion I've used in my career. Its also a great way to show you have initiative. Just be prepared to work for free if it doesnt work out.
Have you emphasised the point of the lower development time. Any person that doesn't want a shorter turn around time is an idiot. This is the only main issue i can think for the change. Or what you could do is develop it on the side and when you have errors say this is what i have been doing in my spare time(have a working copy written in python).
Perhaphs showing him
a)Time spent in developing in Python and Java
b)lines of code in Python and Java
with these two metrics maybe you can make your case stronger
I would guess a lot, in terms of risk management, would depend on the separation/isolation of the various softwares you develop, and their life cycle.
If you don't need to further a central set of libraries, or have (or can develop) Python bindings for those, and the projects are relatively self contained, say a turn around of two to six months, you could give him a quote for a project in Java that is reasonable and he's familiar with (to make sure it doesn't appear artificially inflated). Then give a much reduced quote for the same in py+pyQt, and see if you can get him to invest on your advice.
Without tangible evidence coming from inside that a change in route will bring benefit the more management and economics savvy people who are technically ignorant will not buy into a new platform when the old one never prevented from realizing and selling.
Without a decent assessment of why he doesn't want to switch platform and what he considers risks it's kinda hard to give more pertinent advice.
Just use Netbeans as an IDE and he'll never notice :P
Speaking more seriously: a side by side comparison of strong and weak points behind each of technologies will certianly be more convincing. Just don't cheat too much in favor of Python ;)
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.
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 10 years ago.
As a Java newbie I'm wondering: of all the languages in the world, why is Java frequently used for enterprise applications? What makes it that way compared to the other languages? Will it continue to be this way in the upcoming years?
I'd appreciate your insights. Thanks in advance :)
One word: libraries. Java has an vast array of excellent libraries for solving most of the common problems one needs to solve when developing enterprise applications. In many cases, there is more than one good choice for addressing a particular need, and oftentimes those libraries are free and open source under a business-friendly license.
Some have argued that there are, in fact, too many choices in the Java ecosystem, and that developing enterprise software in Java requires developers to make a large number of decisions that can have far-reaching impact on the end product for better or worse. This has probably helped propel the popularity of alternatives like .NET, which has a reputation of offering fewer choices, but with the benefits of a more well-integrated application stack and tools set. What direction you choose depends, I guess, on whether you place more value on "freedom of choice" or "freedom from choice".
There are lots of reasons a large company (the type to go for enterprise solutions) would pick Java. Note I'm not saying all these reasons are correct or valid. But the relevant point is that they appear valid to a CTO at MegaCorp.
Learning Curve
Java is a simple language without much of the flexibility of other members of the C family, this cuts both ways, but it is seen as a straightforward language for use by an army of programmers. Enterprise projects tend to involve large numbers of developers (rightly or wrongly) and it is much easier to get a developer to a minimum level of competence in Java than C++. You also have a whole generation of graduates who have probably been largely schooled in Java.
Choice
Java has a vast array of libraries, frameworks, tools and IDEs, and server providers. To an enterprise its good to have choice, even if that's just for use as a bargaining chip when negotiating price. The language lends itself to code quality tools that allow enforcement of corporate standards (and as mentioned there are a lot of those tools).
Platform Independence
Java is write once, run (well, debug) everywhere. Sun has actively encouraged open standards that allow multiple vendors to implement their solutions. These standards give the customer the comfort that they can migrate from one vendor to another if a given vendor goes under or starts charging more. Of course the reality is that each vendor does their best to provide some "added value" features that tie the customer to them quite nicely.
Maturity
Its been around a long time, running a lot of servers. If your web application needs to be "6 sigma" or similar and you are the MegaCorp CTO, you are not going to look that kindly on Joe the developer wanting to do it in RoR.
Timing/Marketing
Java came out when programming was moving towards the web. It was positioned cleverly and got a strong position early in web development. Because of the open standards, there are some very big companies producing these platforms and they market Java pretty hard to sell those platforms.
Inertia
Large corporations move forward at a glacial pace (a lot are still using Java 1.4 five years after 5 was released), so once they've picked Java, it takes a massive investment to move to another platform. With each day that goes by they're cranking out more Java that would need to be migrated. Most of these companies are not primarily coding shops, so it is a very hard sell to convince the business to spend a few tens of millions rewriting their entire code base for no immediate business benefit.
Another reason might be the care Sun has taken to keep Java backwards compatible. The vast majority of Java code can be run on the latest version of the JVM without a problem. That is quite an achievement, given the age of Java. On the other hand you might argue Java has not changed all that much in all these years.
Enterprises like stability in a platform.
Sun targeted Java to speak to the needs of enterprises early on. It pushes standards that promote vendor independance at every level. Platform independant, database independant, application server independant, etc.
In addition they promoted enterprise level tools for it, in terms of messaging, transaction management and other things that the enterpise worries about.
Before Java, enterprise level stuff tended to be done in C++ (there were plenty of exceptions (does anyone remember PowerBuilder?) but that was the rule) and Java fits well as a successor to C++ for business applications, where that kind of memory management isn't something worth paying for.
In addition to all of that the language itself speaks to enterprises in terms of avoiding hard-to-get-right constructs that can really mess up a code base, such as operator overloading. Enterprise level applications tend to get handled by many different hands, not all of which are the top of the line programmers, and having safty nets to prevent shooting themselves in the foot is a desirable thing.
It also came along at the right time. A new paradigm (this was well before .NET existed) that promissed to combine multiple vendors into an ability to compete with Microsoft, which got the likes of IBM and Oracle on board, that happened to fill a new hole, which was the emerging requirement to develop web applications, where C++ was no longer an obvious choice.
I shouldn't be saying this, but...
The real reason is because it's named after coffee!
Business is about time, money and opportunity.
Using Java means that your number of errors in the code goes down, simply because pointers are hard. You use a GC and you instantly remove an entire class of errors from your code.
Secondly, Java was one of the first languages to ship with a pre written library of functions, which really did cover a lot of the development phase. This restricted the way things were done but it meant that people could learn faster, had more tools at their disposal and had a great set of libraries to do things like network, GUI, web, encryption etc. Java on its own as a language really wasn't that special, but Java plus the Java API was.
So if you've got a language that has less errors and more infrastructure for free, then you end up with more code in less time. Sure the code doesn't cure cancer, it's not as fast as C++ code to achieve the same task, but it will achieve the business' goal of getting an application.
If you make more code, for less money, you can pursue more opportunities. You then bring inertia to the table in terms of code that's already been implemented in Java and you start seeing why the business doesn't want to move away from their comfort zone.
Personally I believe one major reason is the cross-platform issue.
Java programs written "correctly" (without assumptions of the underlying operating system) can run on any JVM. This means that you are not tied to a particular platform, unlike .NET which marries you to Windows.
I have seen Java code run on mainframes, Linux routers, inside Oracle database, and naturally on PC's.
It's cheap, RAD, cross-platform, and developers abound.
Developing in C++ is too slow and expensive and .NET has not been around for long enough. Business inertia is huge, remember.
Businesses want languages that are backed by a professional provider (ie. a company like Sun) and often stay away from Open Source languages for the simple reason that it was not written by a company.
Also for client-server applications, you have an abundance of choices for production-quality app servers that have the same J2EE interface (IBM WebSphere, BEA Weblogic, JBoss). Alternatively, you could use the Spring Framework on any server like Apache Tomcat the complies to the Servlet API if you're convinced you don't need EJBs. In contrast to .NET, it's hard to find choices with respect to app servers.
There are an abundance of choices with regards to frameworks for a given task be it an ORM tool, logging, collections, caching, web UIs, etc. There is no hardly any need to reinvent the wheel.
Finally, while it's fashionable these days to lament the very real shortcomings of Java the language, it's a language where folks know how to get things done and how to avoid certain anti-patterns.
The other answers are all good. Two things need to be added, corporate standards and the bandwagon effect. If you want to build an enterprise system you need to have pretty strong case for not using your company's entrenched standards and this is mostly JavaEE. And if you need to resource a project it is a lot easier to recruit a Java programmer than it is, say, Erlang.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
A project I was working on has finished, so I've been moved on to some new tasking at my employer. The previous work was very agile, small team, progress over procedure, etc etc.
So anyway, the new project I'm on - I find myself confused on how to deal with management. They have no real understanding of object oriented programing , current technologies or methodologies. They seem to fear change and just recently we moved to the latest JRE
We do these code reviews and I have to listen to "gray beards" saying how much better it is in ADA or how they used to do things in C. But then when they try to code review - they lack even the most basic understanding of OOP design and dev. They focus more on the style of the code; spacing; method names; etc.
One of the senior level people say we should be writing our own logger instead of using log4j because of one negative review of log4j in an academic PDF written ages ago.
How do I deal with this? How can I explain to them that their design is faulty or that they are really behind the times, without coming across as a jerk. I've only been with this organization for about a year - so I don't know how much credibility I will have.
Regarding the code review, I would say make them happy. Name and space things the way they like. Focus your time on better design, of course, and enjoy the ADA reminiscing, it still can give you some background of where things are today and how they got there.
In other words, don't take that part too seriously. Worry about what is important to getting the job done. The job in this case is making those that matter feel you made a positive contribution to the project.
Regarding Log4j, I would just suggest a different framework. Either the built in JDK logging (can't complain about that, it is a built in API) or something like SLF, which lets you plug in whatever you want (including your own, I guess, which you can then throw away and replace with something real when they realize it was a mistake, and you only have to change the classpath).
Now there will be times where it is important. In that case, make it sound as much as possible that it is their idea. For example, on the logging, state that there are many logging frameworks out there that represent a lot of lines of code, and you were wondering if there are other ways to leverage that work for this project, and then let them "figure out" the solution.
There will be times when you have to push something as your idea - there will be no other way. In that case stick to the evidence, martial allies as much as possible by keeping relationships with those that do have influence in good standing, and realize that every battle you fight, you lose position, even if you win (perhaps especially if you win).
I'd recommend approaching your concerns as 'suggestions'. Make a suggestion and ask for their opinion on it, that way they feel as if they are still in control even though you've planted the seed and are directing the conversation.
Regardless of how long you have been with an organization, you are there and you are there for a reason (they hired you for your input). Find your voice and how to best approach your team members with suggestions and/or concerns. This is a crucial part of being a team member and will increase your value.
Get a good formatter and create you method names this which they cannot complain about then your discussion can move onto real issues.
Some people cannot get over these little details during reviews, so you need to make it a non-issue.
Your work has to gain credibility before they will listen to you. So yes, do as others have recommended, and make sure the unimportant formatting laws are adhered to. But also do such high quality work that they can't ignore or marginalize you. Try to guide them in ways that makes them think the ideas are coming from them.
I disagree with the recommendation of another logging framework besides log4j. Citing an old review, without any kind of personal experience, should not win the day here.
However, there might be a way to turn this to your advantage. If you agree and recommend the logging built into the JDK or Apache Commons logging, you'll find that both are quite similar and can actually use log4j as their underlying implementation.
If your adversary isn't paying much attention, you may win points for giving in and avoiding a bike shed argument and STILL get what you want.
Respect your elders I say! :)
Really though, just remember that a lot of these gray beards were probably programming while you were in diapers. That doesn't make them experts in the latest technologies, but it should at least earn your respect. And sometimes if you can find a way to look past all the hemming and hawing and "back in my day" stuff, you can pick up some pearls of wisdom from those old dogs!
Now from the programming perspective, looks like Yishai has it right. It should be pretty easy to conform to the coding styles they want, and once you've made them happy you can run with the code the way you want.
And if you have to present a counter opinion, back it up. If you want to use something like log4j, talk about SPECIFIC projects in your past where you've used it and it worked fine, and offer to help anyone get past any problems they have with it, etc. etc.
Remember, while you look at the old gray beards as not knowing how to do some cool new programming, they probably see you as a young whipper snappers with a lot of crazy ideas out to change the world. An ounce of patience will get you a pound of respect.
I am an old gray beard but I abandonded COBOL 35 years ago and code in dotNET C# and have kept up with the young wippersnappers and try to mentor them too. With that said I see a lot of managers and programmers that are still in the dark ages like VB6 and cannot accept web farms, web services some of these gray beards and young wippersnappers cannot normalize a database table to 3NF let alone code nTier, WCF or have a clue. Worse yet some of the managers are 30 years behind and rely on the VB6 at best and a flat file using Access97.
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!