aspose file tools*
The moose likes Agile and Other Processes and the fly likes What do you do when you can't program BOTTOM-UP? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "What do you do when you can Watch "What do you do when you can New topic
Author

What do you do when you can't program BOTTOM-UP?

John Morkus
Greenhorn

Joined: Jul 07, 2004
Posts: 17
I'm in a project where the client is asking for public "API" interface methods when the design hasn't yet been done. The ink on most of the requirements is still wet. Plus there are delelopers in multiple states and no testing CVS server yet.

There's a lot of code written that will mostly be thrown away (go figure).

How do you "push back" when political decisions start to drive a project?

How do you tell a client that it doesn't make sense to put the cart before the horse when he's trying to make sure the horse and the cart aren't taken away (reacting politically rather than technically)? While I agree that you need a project, you also need one that can succeed.

Difficult questions.

Any input would be vastly appreciated!!!

John
Tom Passin
author
Ranch Hand

Joined: Aug 08, 2004
Posts: 30
Actually, it doesn't have to be as bad as it sounds. In fact, developing the API can be part of the work of evolving the requirements and the design. For example, if there is a requirement for a list, you can try to arrive at a list API well before you actually implement a list (of course, you may have to experimetnally implement a few lists as you go to learn enough to write a list API).

Once you have a domain model (as opposed to an implementation model) - and you really should have one - you can start thinking about an API.

So I'd suggest that you plan to deliberately use the API development process, if you are forced to do it, as an opportunity to test and exercise the requirements, and to help get your design in order. Remember, the API doesn't have to be closely tied to the implementation, and probably shouldn't be.

In fact, if you are doing OO development, every time you design a class you probably design its API first (i.e., its public methods). This is the same thing, just at a higher level than a class.

Just make sure the client knows that the API is subject to change, just like any other alpha software.


Author of <a href="http://www.amazon.com/exec/obidos/ASIN/1932394206/ref=jranch-20" target="_blank" rel="nofollow">Explorer's Guide to the Semantic Web</a>
John Morkus
Greenhorn

Joined: Jul 07, 2004
Posts: 17
Thanks for your note.

I liked your example of a list and understand what you're getting at. If I could break down the project to that level of detail and the requirements were at that level, there wouldn't be a problem.

The problem domain is actually custom (to-be-written) Java applications that would have to authenticate with a yet-to-be compelted JAAS module (to work with both NT or database login -- how, yet to be figured out) and either directed to a login page if the user doesn't exist or get some type of session object back if the user does exist.

I'm not yet sure how the security object, based on the programmers who would use it, would be instantiated. (Or whether the programmers would just extend what I've written, or some other way...).

Have you run into a project like this where it seems everything must be permitted (allow for all, some or none) for just about every context yet little is really designed?

Thanks again.

John
Tom Passin
author
Ranch Hand

Joined: Aug 08, 2004
Posts: 30
OK, you already have enough information to start thinking about it. First of all, should your security object actually perform the redirection to the login page? Probably not - keep security operations out of page operations!

So you will be handing some package of security credentials to your security manager. The manager will return some object representing the authenticated user or something else if the user does not exist. Good, your security interface must have a method like "verifyUserCredentials()", or "findUser()", that will accept a "credentials" obect and return a "user" or "authenticatedUser" object.

See? You already can see the outlines of this part of the API. Next, you can hack up a toy version of a class that implements this interface and start playing with it to get more experience. That's an example of what I meant about the API work helping you with the design activity.
John Morkus
Greenhorn

Joined: Jul 07, 2004
Posts: 17
Thanks.
Eusebio Floriano
Ranch Hand

Joined: Mar 07, 2004
Posts: 235
Originally posted by Tom Passin:
Once you have a domain model (as opposed to an implementation model) - and you really should have one - you can start thinking about an API.


What did you call "domain model" ? Is it the business rules of the system ?
Is it associated with an specific technology or it is an generic solution ?

Regards,


SCJP 1.4 / 5.0 - SCBCD 1.3 - SCWCD 1.4 - IBM 484
Tom Passin
author
Ranch Hand

Joined: Aug 08, 2004
Posts: 30
A domain model is a representation or model of the "domain" - that is, the part of the world - in which your system will be providing services. It is expressed in terms from that world. You need to do this first, so that you can understand what problems you will be solving or what services you will be providing.

For example, suppose you are going to develop an ATM system. You would have bank entities that own ATMs and customers who have accounts and use the ATM. You would have bank transactions and cash amounts. You have to know about these kinds of things before you can start to design a software system to control the ATMs.

So a domain model will likely include business rules but goes beyond them (depending on how you define "business rules", of course). A domain model will generally use terms and concepts from the problem domain, rather from the domain of software and programming.
Eusebio Floriano
Ranch Hand

Joined: Mar 07, 2004
Posts: 235
would the domain be the definition of all the entities of my system and their relationship ? that�s it ?
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by John Morkus:
I'm in a project where the client is asking for public "API" interface methods when the design hasn't yet been done. The ink on most of the requirements is still wet. Plus there are delelopers in multiple states and no testing CVS server yet.


First, understand that API design and development is different than closed application development. You need to consider how it will be used, now and in the future. You are not solving a "problem," or creating an algorithm, but trying to anticipate the needs of others. You API needs some logic and consistency to it. Most importantly, public APIs generally are set in stone because you have legacy issues.

As you know, requirements, schedule, and design are not toally independent in most modern methodologies. they tend to overlap and interact. The same is true with APIs. In some sense, the API is more decoupled than the design (although design affects API and visa versa). The API is how the public accesses the underlying software capabilities. It's an abstraction layer designed to hide what's underneath, so you can, in theory, design how you want, and then put a facade over it exposing APIs. Obviously different designs make certain API schemes easier and others harder.



Originally posted by John Morkus:
How do you "push back" when political decisions start to drive a project?

How do you tell a client that it doesn't make sense to put the cart before the horse when he's trying to make sure the horse and the cart aren't taken away (reacting politically rather than technically)? While I agree that you need a project, you also need one that can succeed.



This is a more general issue. The be successful you need to be fluent in multiple languages. One language is software: understanding designs, scheduling, costs, technical constraints, and general project management issues. The second language is business: business needs, market timing and demands, competitive pressures and forces, organizational constraints, possible legal issues, etc.

Most of us only see one side. Those who are successful can see multiple views of the project. As an MIT dean likes to say, "it's often easier to teach the business skills to the tech guys than the other way around." This is the key, btw, to surviving off-shoring. This is a lot harder to do trans-continentally.

Here's my biggest tip for doing this. Whenever we speak, the following haapens: you get an idea, you translate your idea into words, they hear the words, the translate the words into their mental model. Each step allows for noise to distort the ideas. The biggest jump is from your words to their words. Engineers think differently than others. For example, we talk about space time trade-off. Laywers talk about compliance. Economists talk about time-value trade-offs. Historians look at events, patterns, and cause-and-effect relationships. At a basic level we all understand each other, but at a more subtle level we don't. Whenever I approach a client or customer my first job is to learn to speak their language. The closer I come to understanding how they think and speak the closer I'll be able to express my thoughts in terms they naturally understand, and the chance for misunderstanding decrease.

--Mark
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
Welcome to the REAL world of software development.
While the academicians talk about process, workflow, etc. etc. in the real world code is produced as needed.

More often than not the design is either created afterwards to match the code or is created alongside the code and adapted to match changes in the code.

Sometimes this is the case with the requirements as well...

I've rarely worked in an environment where this wasn't happening in 7 (running on 8) years in the industry (and 6 years in studying applied physics (rather than some theoretical IT curiculum) before that).


42
Mike London
Ranch Hand

Joined: Jul 12, 2002
Posts: 1034
After just reading the updated version of Code Complete (2nd Edition),
by Steve McConnel (M$ Press), a fantastic read, I'm amazed with all the studies, failed sofware projects and 20+ years of other anecdotal evidence that people still (as in my project's case) still *try* to create (working)
software this way (create an API before any real design is done).

I see everyone's point of view here, and my suggestion is why don't you maybe enlist the help of another team member to sit in on some meetings with the client to see if they can help you see what he wants. It sounds like you just need a good understanding starting point to jump in.

Since your project is early on, it reminds me of a mountain climber searching for a good toe hold (or some kind of traction) on an icy slope! I'm sure this is a common feeling with large dispersed projects.

I like the idea of creating a facade over whatever API you came up with, but
at the same time, I'm sure it's stressful to have a bunch of other developers starting to program to an API that's more or less "PFA" (Plucked From Air) knowing it will have to be changed later (but hopefully not by using a facade or other mechanism, of course).

No project is ever perfect.

I'm sure things will smooth out in time...good luck.

-- Mike
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
Moving this to the Process forum...


[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I like the facade idea. I had an interesting (I wouldn't say ideal!) experience breaking an app into architectural layers and business function solos with a small team for each square in the matrix. Each team set up a facade. When somebody said "I need a new service from you" they could throw a method on the facade that always returns true or returns some randomized strings or something that let the client team start building and testing right away. Then they could sit down and take a while figure out a good implementation.

Focus on layers of abstraction so you can design APIs without knowing what happens inside them, and isolate contact with the APIs to as few classes as possible to changes will hurt as little as possible.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: What do you do when you can't program BOTTOM-UP?
 
Similar Threads
SLSB & SessionSynchronization interface
Rules for Constructors - K&B Page 315
Kathy and Bert's bit parts at an Icelandic Horse Show
casting classes and interface - need some clarification
constructor chaining - why?