WebObjects Development
Volume Number: 16
Issue Number: 10
Column Tag: Managing a WebObjects Project
WebObjects Development Lifecycle
by David K. Every
What does WebObjects do?
Article Scope
There are many parts to making a successful web-solution. The success or failure will
be based on how good you (or your company) is at being an engineering company,
engineering team or at least engineering project. If you aren't an entire engineering
company then you are going to have to emulate all the facets of being one. If you don't
have the size and experience, and are approaching the problem on your own or with a
small team, then you need to try to all wear many hats in order to make sure all the
parts of the project run smoothly. Each part is important and will help you avoid
pitfalls - so don't discount them.
It is beyond the scope of this article to explain all the concepts necessary to manage a
successful team, how to do proper analysis, scoping, design, project management, as
well as explaining how to be an interface designer, DBA and data architect. But it can
sum up some of my experiences (many hard learned), and hopefully give the reader an
introduction or review of the high level concepts on what to do, what not to do, and
what are the warning signs to look out for.
This article is also tailored towards WebObjects project management - assuming an
"average" project. Your project might not be average - but you can think about how
you can borrow ideas and concepts, and how this information might help you..
Balance
The key to creating a successful project is balance. Always remember the balances and
tradeoffs. You have to balance your goals, with the customers desires. You have to
balance marketing with engineering and with financing. You have to balance features
(power) against simplicity (learnability) - and form (style) against function
(usability). You need to know your customers (marketing and feature), but you need
to know what you can develop (engineering) - all balanced with what you can afford in
time and money. There are many seemingly conflicting goals, and all of them have to
weighed against the others and balanced. Everyone is not going to get exactly what they
want - but if each gets to keep the important things, and they get it in balance with the
others, then the product will probably be better than if there is no balances at all.
Balancing the needs (and communicating them) is done in order to get everyone on the
same page, and shooting for the same goal. Even if meetings seem useless or time
wasting, they are valuable if you can build some consensus or let people feel like their
views have been aired (and really listened to). Even if they don't get what they want,
you are more likely to get buy-in if they feel they have a voice and win some of the
time. Even spending time exploring paths you aren't going to follow can be very
important, if they can at least explain why the company isn't going to do something, or
why things are being done the way they are. This makes your decisions more defensible
and better understood. So meetings can be a tool to create consensus and understanding
or they can decay into adversarial places where there is little real communication -
always strive for the former.
Conflict is going to be natural in the process - people are each advocating different
views or different parts of a solution which are critical to them. Accept that conflict,
don't take any of it personally, and don't hold grudges and try not to allow others to. You
need to express a view strongly, and get over the fact that others won't agree and you
aren't going to get everything that you want - if you can't do that, then you certainly
shouldn't be involved in engineering. Remember that you all have the same goals - to
build the best product possible, in the least amount of time (with the lowest costs).
Engineering is about tradeoffs and balancing all the differing desires - but you are all
shooting for the same prize. Keep reminding people of that, and keep reminding them
that things will evolve and not getting something now, may only mean for a while. Good
ideas will keep coming back, and eventually win - and often things lose because it is
just not yet the right time for that goal, but not that their goal itself is bad.
Unfortunately there is no magic to knowing where the lines should be drawn, when a
project is unbalanced, and what to do about every situation. Nor is it easy to know
where to cut off communications on certain paths, or all the nuances of managing
people and delicate professional egos. That is all stuff that you just have to learn by
experience, and there are books more targeted towards those subjects. However, if you
at least remember to watch for balances, make sure that people are being heard and
that your team is building consensus (and not hostility), people are learning why and
where compromises are being made, and you are keeping communication open and
constructive (with the eye on the prize), then at least you have a head-start on
creating a successful project.
Managing the process
There are many books on the theory of analysis, design, and development. Many explain
how to decompose problems from different points of view, and different methodologies
for OOA (Object-Oriented Analysis) or OOD (Object-Oriented Design) - and many
more on the older procedural analysis and design processes. Some explain techniques
for drawing how things relate, nomenclatures, methodologies, and mental exercise to
break problems down, and so on. This article is not one of those books. I've read many
of those books, and I'm not knocking them - they have value and I recommend reading
many of them, they have many nice insights that can help. However, most companies
just don't have a staff of people all trained in the same methodology, at all levels of the
company, in order to do a good job with them. Without a deep understanding of the
processes (at the management as well as at the engineering level ) then the processes
can quickly become less than efficient - and the results will probably not meet
expectations.
The point of what analysis and design is really about should be as much about getting
people on the same page, getting them communicating well, managing expectations and
getting some consensus and agreement on what will be done. It is setting targets that
people understand and can shoot for, and measure progress against those targets so you
can get better over time. The processes, documentation and drawings, and exercises in
many analysis books and classes are not the ends - they are just ways to try to achieve
the ends (communications, consensus, repeatability in forecasting, setting goals and
managing expectations).
Many of the larger, complex processes may be necessary and valuable on larger
projects (say 15 engineers or more) with multiple teams, huge development cycles
(over a year), and huge amounts of investment. However, successes in those processes
are far more rare than the failures - especially if people aren't willing to be adaptive,
or willing to accept the facts on scheduling or scope that is often staring them in the
face. I've found that those processes are usually overkill for creating most
web-applications.
WebObjects is a powerful rapid application development tool that makes programmers
much more efficient than many other tools. This magnification of programmers
efficiency means that smaller teams can do more - and thus more projects are smaller
with WebObjects than they would be without it. So the project management processes
(including analysis and design) can be a little bit lighter as well.
If you have a large team, of highly trained people, or a well established process that is
working for you, then I'm certainly not suggesting that you throw it all away and try to
mimic the suggestions of this article. Stick with what works. But there are many who
are unsure about how to approach WebObjects development, or looking for alternative
ways of thinking about that problem. This article is about techniques that I've learned
and used in startups and larger companies to help establish a sensible process (or
streamline one) for doing WebObjects development and project management. These are
ideas for how to manage a WebObjects project (smaller, rapid development projects),
while still maintaining a useful amount of documentation and process in order get
things done right, and to still allow engineering enough critical communication to work
well with other groups such as Quality Assurance, Documentation, Marketing,
Management and so on.
Go Visual
If you verbally describe something to a group of people they will each imagine
something different - they may think that they are all talking about the same thing,
but in their minds they are picturing something that might be quite different from the
rest. When one person delivers on what they were saying, the others often find that it
didn't meet with their expectations - and nothing seems to get people more frustrated
then having something fail to meet their expectations (ask any married man). The
further away you are from their expectations, the worse things are likely to be - so
one of the keys to successful project management, and a happy life, is good
communications and managing expectations.
If you write a document that describes how something works, people are more likely to
be on the same page than just speaking the same thing. Speech is more imaginative than
writing, and words on a page can be less ambiguous. Also people can digest written
documents at their own speed, and review until they get it. So a well written set of
design documents can really help facilitate communication.
Unfortunately, people are still victims of their ability to write, read and digest these
documents - and those are skills that take time to master. Most design documents are
not very good and tend to take up lots of time to create, with little results, and tend not
to survive confrontation with implementation - so by the time the product ships they
are woefully out of date. Many people aren't willing to read long design documents -
and just ignore them. So while design documents are usually better than just verbal
concepts, written words usually aren't good enough to get people to understand what
others mean.
Most people tend to be visual and understand what they see, and they don't have to
conceptualize the intangible based on your description. Thus the key to successful
documentation (or many discussion) is pictures and drawings. This is why many
restaurant menus have pictures - don't describe it, just show it. Don't be afraid of a
white board, a sketchpad, or a drawing program. It is cliche, but sometimes a picture
really is worth a thousand words - and people are more likely to use the picture than
they are to read the thousand words. A few simple drawing, with notes and points can