Sponsored Link •
Andy Hunt: It's a multiple choice question. It's not like we have no idea how to deploy, just pick something and make it up. Marketing says they might deploy the system like A, B, or C, but they don't know yet. They aren't going to know until it's far too late in the game, therefore you have to be prepared for any of A, B, or C.
Dave Thomas: In fact, our previous client had exactly this happen to them. They knew they wanted a client-server application, but they weren't too sure how they wanted to present it to the user. For months they went back and forth between using an applet or application on the front end. They did this as they were writing the program. If instead they'd stopped to work out exactly what they were doing up front, they would have delivered the code four months later. Since they didn't know which they we're going to do, they in effect decided to code both an applet and an application. Because of the way Java works, it turned out coding for both added very little overhead.
Andy Hunt: There was basically just a thin wrapper for each of the environments, and from that point backwards everything was the same.
Dave Thomas: They could actually choose between applet and application by changing a couple configuration files.
Andy Hunt: That depends on what you mean by the requirements. If you're talking about the formal written-down requirements document, yeah, we're probably going beyond that. But we're not going beyond what we've gotten from talking with the user and from seeing the environment. You would never go beyond the requirements just on a whim, or just because you thought it was cool. There must obviously be some need. Maybe it's expressed directly by the client, maybe not. Maybe it's implicit in the environment. The client may not be aware that something is going to be a problem directly, but there may be other ways to tell it is going to be a problem. You know from the situation. It would be irresponsible, bordering on malpractice, just to put in extra adaptability where it's not needed.
Dave Thomas: I can give you an indirect example. We had a house built when we came to the states. We talked to the builder about what we wanted. Among other things, we told him we wanted a lot of storage space. The builder came up with some plans that looked wonderful, and started building. As they got to the sheetrock stage, he was walking around and noticed an unused alcove. He realized if he sheetrocked the inside of the framing of the alcove, he could actually form a new cupboard. He took some scrap sheetrocking and put on the inside of this alcove before sheetrocking over the alcove. The next time we saw him he said, "I've done sheetrocking inside, do you want me to cut a door through and make a cupboard out of this? We said, "Absolutely." So we got one extra cupboard.
By sheetrocking the frame at that stage, he saved us the hassle of saying, "Hey we could use that space. Rip off all that sheet rock you just put on the outside so we can sheetrock the inside." He'd gone ahead. It wasn't a stated requirement. It wasn't on the plan. But he knew what we wanted, and based on that he made a decision.
Andy Hunt: That's the key. He knew what they wanted. It's a question of intent, not necessarily a stated requirement. We know they want cupboard space. We know this is a big goal of theirs. We know this is their intent. We are going to try and meet that any way we can.