Sometimes a team finds themselves with requirements that require a lot of back-end development and a small amount of front-end work. If the team has specialist front-end and back-end developers then it may be tricky to balance the workload.
One approach I have seen work is to initially stub the back-end functionality before doing the detailed development work.
When you do something often, you get good at it. So deploy to all environments using the same mechanism. That way, when you deploy to production things less likely to go wrong.
It has long been a tradition in waterfall style projects to associate long hours with increased productivity. A recurring pattern is up-front planning, followed by realisation that a deadline is not going to be achieved and then finally a push to increase working hours.
A word of caution for anyone switching to Java 8 (which is now officially released by Sun).
Issues I have found so far:
The previous version of Kepler Eclipse runs with Java 8, but it only understands compliance levels up to Java 7.
When we talk about non-functional requirements we often focus on performance and response times. But there are many other types of non-functional requirements and their obscurity can lead to them being missed.
Here are some non-functional requirements that can get forgotten:
In my career I have seen the transition in popularity from FORTRAN to Pascal, from Pascal to C, from C to C++ and from C++ to Java. That is not to mention the introduction of Hibernate, Spring and numerous other technologies.