© Sten Vesterli 2013 @stenvesterli, sten@vesterli.com, www.vesterli.com

1

Worst. ADF. Project. Ever. Sten Vesterli Twitter: @stenvesterli Email: sten@vesterli.com Blog: www.vesterli.com

Introduction There are good projects. And there are bad projects. And then there are the projects from hell where everything goes wrong. This whitepaper presents ten things that can go wrong on projects – most of them are general project issues that apply to every technology, but a few are specific to the Oracle Application Development Framework tool.

1. Don’t play “Telephone” In this project, my company was a subcontractor and had no access to the actual end users. This is like the children’s game of “Telephone” where a message is passed along from person to person until it is completely garbled.

Without easy access to the customer, the written requirements binder is the only information the programmer has to work on – and even the most carefully worded requirements can be implemented in multiple ways.

2. Don’t start with the full team It does not work to total up the number of man-months needed to build a system, looking at the schedule and then calculating the number of developers needed.

If you start out with the whole team without first establishing the architecture and a standard for development, your team will run off in different directions leaving you with a system with much less internal consistence than it should have.

3. Beware of feature creep All projects potentially suffer from feature creep – the slow addition of more and more features that were not in the requirements and for which resources have not been allocated.

The risk of this is especially acute in projects with very powerful technology like Oracle ADF. The standard components are extremely capable, but also have limitations. Until you have experience with where the limitations are,

Worst. ADF. Project. Ever. Wildcard 2013

© Sten Vesterli 2013 sten@vesterli.com

2

there is a definite risk of promising the customer something that proves to be very hard to implement in ADF.

4. Know your tool If a significant part of your team is new to the chosen development tool or approach, do not jump straight from a training course and into building production code. If you do, you will make poor architectural choices and write over-complicated code.

5. Keep Priorities Straight In any project, some features prove harder to implement than others. If the customer insists on every feature being built exactly as specified, you will waste a lot of effort on trivial, but very hard-to-solve issues.

6. Appoint a Nutcracker If your team is new to the technology, appoint a “nutcracker”. This is the person to crack the tough issues you meet and find out how to make the tool work best for your team and project.

If you do not assign at least part of someone’s time for this task, your team will waste time as junior programmers try to solve hard problems. You will also end up with various sub-optimal solutions to common problems.

7. Start with a proof of concept If you do not build a proof of concept at the beginning of the project, all assumptions on development speed are mere guesses. This is a recipe for over-ambitious schedules and a team that is continually behind schedule.

8. Don’t release too early Once you are behind schedule, it is tempting to start to cut corners and release questionable code. That never works and your flaky code comes back to haunt you during the rest of the project.

If you are behind schedule, re-negotiate either the schedule or the scope for a specific milestone. Skimping on quality does not work – and neither does adding more developers.

9. Manage Expectations Developing applications with a powerful component framework like Oracle ADF poses an expectation management challenge. Your users can see you work magic and implement very advanced features easily, so they start believing that everything is possible.

Worst. ADF. Project. Ever. Wildcard 2013

© Sten Vesterli 2013 sten@vesterli.com

3

It is important to explain that when we can work with the grain of the tool, we can implement a lot in a short time, but if we try to work against the tool, things get hard, expensive, and slow.

10. The notorious “Back” button The default way a developer implements an ADF application is as a rich internet application with page fragments. This gives the application a ”desktop” feel where only the necessary parts of the screen refreshes when the user interacts with the application.

The users like that, but they also want the browser ”Back” button to take them back to the previous screen.

Make sure from the beginning whether to use pages or page fragments and explain the difference to the end users.

Conclusion This paper describes ten things that can go wrong in a project. Keep these in mind as you plan and execute your own project so you can deliver on spec, on time and on budget.