1. © 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,

2. 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.

3. 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.