This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hi guys, I have been studying Java/J2EE since past one and a half years. I work in a company and am working on different technology, which I am not interested in. I will be completing 2 years here in Sep and would like to switch after that in Java/J2EE stream.
So I just want to know how a corporate experience in Java/J2EE is different from the experience we get by working on our own small projects and all. I want to prepare myself so that I can ensure the recruiter that though I have not had real experience but I have knowledge to do it. What will the interviewer expect from me and is this possible?
Here's a few general differences between small-scale student projects and "enterprise" projects on any platform:
1. What is the purpose of the project/system?
For a study project you usually know what your users want, because you (or your tutors/colleagues) are the users. Real enterprise projects can struggle to define the scope sufficiently to ensure the project can be completed with the resources available. This is a particular problem in the public sector, where nobody wants to risk committing themselves to a clear statement that "We want you to implement X" in case they are held responsible for any problems with X later on.
I've worked on JEE projects that have been through the entire development life cycle twice, and the business users still can't decide what they want the system to do. This is a tough problem to solve on large projects, because Big Up Front Design doesn't work in many cases either, but poorly managed Agile approaches can allow people to postpone all the hard thinking until it's too late to do anything difficult because all the money's gone: Agile is meant to help us refine requirements as we go, but can sometimes end up concealing them.
2. Avoiding the hard stuff
Most toy projects never really confront serious technical challenges e.g. a student database application won't usually be trying to support thousands of users on a terabyte database. Anyone can hack a SQL query to get the results they want from a single table of 1000 rows (or get Hibernate to do it auto-magically), but it takes a lot more skill to implement high-volume database functionality efficiently, reliably and robustly. The same thing applies to many other areas e.g. networking, performance, security, and of course ongoing support/maintenance. Many aspects of any "enterprise" project require specialist knowledge and experience that can only be acquired the hard way by working on several big projects.
3. Reliability and robustness
Toy projects do not usually have to satisfy serious criteria for reliability. Test-driven approaches help to ensure that individual components do what they're supposed to do, but many of the problems on an enterprise project emerge only when you start to put lots of things together, and comprehensive integration testing and UAT are rarely part of any student project. But when your customer might be paying millions for their system, you need to put a lot of work into making sure it's fit for purpose. Which can be even more difficult when the client keeps changing their mind about their requirements (see 1 above)!
Student projects are great for hacking out code, because you only have to care about the functionality and probably nobody else will ever read your code anyway. But enterprise projects are created by large teams of developers who may have to maintain the system for many years. Many other people will have to look at your code and modify it over time, and all the "black box" UML documentation in the world won't make up for failing to write or test your code properly in the first place. And of course you also have to rely on your colleagues doing the same thing e.g. if you are working with components developed by another team.
5. Large teams
It's easy to coordinate your work on a study project with a few fellow students, but really big enterprise projects may have large teams of developers/analysts/designers/architects working on different sites or even in different countries, and perhaps working for several different companies. Each interface between developers/teams/countries/companies introduces extra delays and opportunities for confusion/obfuscation, adding to the potential for problems with communication and coordination. This can have a massive impact on costs/time, which in turn impacts the ability to deliver the project on time/budget with the required functionality.
Your student project probably doesn't have to worry too much about departmental politics, but an enterprise project can be crippled by political wrangling over budgets, scope, respnsibility for delivery, engagement from senior business sponsors, and so on. For example, you might have business user representatives who are supposed to help you ensure the users get what they want, but the users may not want a new system at all because they're comfortable with the old one, so their commitment to making the project a success is less than 100%. Any activity involving large groups of people is inevitably going to suffer from political conflicts, and even as a developer, your work will be affected.
7. Financial awareness
It's obvious, but if you're working on a student project, nobody's worrying about the financial budget. On a real enterprise project, there is constant pressure to control costs in time/effort, which can impact what you are asked to implement and how. There is also a common tendency for inexperienced graduates to get side-tracked by chasing "cool" ideas or re-inventing the wheel at the customer's expense, rather than keeping a tight focus on delivering what is actually required using existing resources where appropriate. It may be that your "cool" idea cannot be adopted because the time/budget/skills are not available to implement/maintain it. These non-technical factors are rarely a feature of any student project, but you have to learn to live with them on enteprise projects. Maybe we should all have taxi-meters on our screens to monitor the cumulative costs to the project of our individual involvement...
Anyway, that's my somewhat jaundiced view of some of the differences between small student projects and enterprise projects. And that's without even looking at things like Death March Projects.
I'm sure the JavaRanchers will offer you plenty of JEE-specific tips for enterprise Java projects.