Why Isnt Sam Coding Yet

Student: I am participating in a CS project, and our task (we're a group of 8) is to create a client-server application to solve / run geometrical problems. We feel that we don't get the care we expected to get, and so we'd like to hear some opinions from people with more experience than we have. We've just started with our OO design and have already run across several issues which seem to break "good" design principles.

...the application will have to consist of a client and a server part and has to be implemented in Java... Different clients connect to the server and form "discussion groups"; each group is dedicated to a certain (fixed) geometrical problem as ConvexHull? calculations or VoronoiTriangulations?.

The server's job is to accept the client's network connections and assign the clients to the groups they request. There will be no client-client communications, so the server has to broadcast some of the messages transmitted by clients to the other clients of the same group. It does so without knowledge of what the clients are communicating, so we have client-server commands the server has to execute (e.g. enter a new group) and client-client commands the server has to broadcast.

The clients "discuss" problems based on a math library we will have to implement among the other things. All clients participating in the same group are supposed to have the same data to base their calculations on, but each client will do the calculations on its own. However, each client is allowed to contribute new data (points, line segments and the like). So if a client issues a new line segment or point, the server will broadcast this within the group and make sure that all clients have received the same data. Once data is consistent among all clients of a "group", any client in this group may issue a "start calculation" command in order to trigger the problem solving process in all clients.

...Can you recommend any starting points for this? DesignPatterns? Are there any "BestPractices" or recommendations on how to implement such protocol classes? It would be nice if we could use the same class(es) implementing the protocol on the client and server side. But what could such a class or set of classes look like?

Me: CodeUnitTestFirst, DoSimpleThings, RefactorMercilessly, UnitTestsDefined, TestInfected, SolveForSpecialCaseThenSolveForGeneralCase, OnceAndOnlyOnce, TestDrivenDesign

Now what's most important is each of your features is tested first, not designed first. This means you can experiment with the design, in tiny little cycles, until it is clean and as compact as possible. After each cycle you will get an "All tests passed" ensuring the odds your experiment produced a bug are extremely low.

Student: I'm afraid of coding before thinking. It may be fun, but also a lot of unnecessary work :)

Me: Your question implies you think you must design your entire object model out of thin air before any coding can begin. I wonder where you students got that idea ;-)

Student: Our professor warned us of the WISCY-syndrome: "Why Isn't Sam Coding Yet?" :)

Now can anyone here help this poor confused student? or his professor???

I think the rather misguided interlocutor is confused and needs help, it's not the student. He suffered from brainwashing strain of XP propaganda. It's not about object models that the student has to think, and he'd better think. If the problem as related by the student is described correctly and no unnecessary assumptions are stated, then all the XP blah blah blah that is repeated like a broken gramophone regardless of context is not gonna produce a lot of worth of good code for this case. --CostinCozianu

I'll have a go:

First stand back from the problem. A long way back. Ask yourself what is this all for? What do you want from the exercise? What does your professor want from the exercise?

It's a learning exercise.

You're hoping to get credits on it.
The professor wants to feel he's taught you well.
You want something useful to talk about in interviews later.

When I read the problem description it sounds so artificial. When I've done triangulations and convex hull stuff, it's been in the context of graphics software, e.g. triangulating on points that overlay on a bitmap prior to morphing the bitmap. That's an actual real world use of a triangulation. The described application is not a full application, so how do you see what is going on?? My alarm bells also ring when I hear that you are in a team of 8, so all the problems of team work to solve too...

The approach I'd take is to entirely on my own prototype the voronoi triangulation software (as a stand alone non client server based java application) with a reasonably nice front end, then present it to the team to cannibalize and client-serverise.

(Tip: Canibalize into ModelViewController and CommandObject. Client-serverise with HalfObjectPlusProtocol and possibly TwoPhaseCommit. Use Java's serialization and applets/servelets. Don't bother with rmi and absolutely refuse to use ejb. Have teammates research these and make them responsible for the corresponding parts of the report.)

The front end is going to be vital to testing, and it's also highly visible. That's why it's important that YOU write it. The visibility gives it a disproportionate amount of kudos. In my MSc dissertation I included color photo screen shots of an application I wrote. My approach of a glitzy impression paid off handsomely as I won a prize for best MSc that year. Do a front end up front, even if it's not an official part of the spec, it will make your life easier and it is an aspect of CodeUnitTestFirst. The triangulation stuff is maths so is seen as 'difficult', which it isn't. If you code the triangulation part too, then you've clearly contributed to the team effort and proved you've understood the maths. Oh, also before all that start by planning your write up, because that is what you actually pick up marks on. You want to put a reasonable amount of time into the write up and not spend all your time coding. Or arguing with the other 7 about how to divide up the problem. Me cynical?

You could spend forever arguing the actual message sequences and 'protocol' to send by between entities. You are much much much better off having something to show that does something early. What you start with can be refactored out of all recognition later, always with something that works along the way. With the approach suggested here, even if the team is unable to work well together, something worthwhile will still come out of it. However assuming a decent team, they will seize on the working code and start working out sensible messages / class splitting between client and server. (See Tip above) -- AnonymousDonor(s)

The WhyIsntSamCodingYet syndrome serves to remind us that there are managers out there who do not understand software quality and who are setting schedules arbitrarily. The guy who asks about Sam is not interested in your prototypes or refactorings. He wants code written today, he wants a demo this afternoon, and as soon as you demo something interesting, he wants it released. Code clarity is way down on his list, not even there. Same for your future problems. He wants you to babysit his customer to whom you just released crap while you fix what's wrong and keep Sam coding (without a clue) for the next round. Some have found this cycle less than optimal. So, recognizing this question as part of a foul dynamic is a helpful thing. Let's not chuck that in order to be glib and extreme.

. . .

The system described above seems to have two interesting parts. One would be the solving of difficult mathematical problems. This difficulty would exist with or without a collaborative model. The other interesting part is the collaborative model itself. The assignment was given in terms of "client-server". The student may be searching for the BlackboardMetaphor architectural style, in which a problem space is shared and accessible to multiple solution agents, each of whom may have expertise pertaining to a subset of the whole problem. These students may not want to have to reinvent blackboard from scratch. Further, after researching blackboard a bit, they may decide that it and other collaborative models are a bad fit for the scope of the current assignment. Nonetheless, an awareness of the blackboard architecture is likely to help decide how to respond to this part.

-- WaldenMathews

I'm afraid of coding before thinking. It may be fun, but also a lot of unnecessary work

I believe this statement is based on the belief that changing code is unnecessary work, while changing design documents is not.

There is simply no way to avoid iterative learning and understanding of a task. An individual or a group is simply not going be introduced to a new project and magically become fully knowledgeable. The only choice is the medium to use when investigating the problem.

In some types of work, there are some very real costs to trying the real thing, so a surrogate is used. One would not iteratively enhance the foundation of a building as new floors are added; it is simply too expensive to shore up the structure, tear out the old foundation, and repour a new foundation. Software development, however, does not fit within this category.

In software development, the costs of creating detailed, correct, and non-ambiguous text are no higher than the costs of creating detailed, correct, and non-ambiguous code. The costs of correcting text while maintaining consistency is no less (and may be higher) that the costs of correcting code while maintaining consistency. The costs of editing text to improve format, punctuation, spelling, and grammar is no less than the costs of refactoring code. The advantage of using the code as the design medium is that when one is done, one is truly done. With a textual design, one still has to write the code and verify that the code conforms to the text. Finally, the code is much easier to validate for correctness than the text (which is why requirements documents, design documents, etc. are so rarely validated and full of oversights, inconsistencies, and downright false statements).

Iteration in a development environment is unavoidable. Unless there is a true cost saving in using a model of some sort, it is much more effective to perform this iteration with the real thing. Software development falls into this latter category, so the question really should be WhyIsntSamCodingYet?

When I saw the link I thought the page was going to be about the effectiveness of "SAM's Teach Yourself..." books and their ilk.

OK, OK, OK!!! I'LL START CODING ALREADY! Just stop harassing me! --Samuel A. Falvo II

I thought this wiki page would provide some illumination on "WISCY", and perhaps even something that would be linkable. Instead most of the comments are so far off topic, it is laughable. WaldenMathews is the only one who contributed something of value.

WISCY is a common dilemma faced by a huge number of developers. I think it is most likely to appear in shops where software development is not the core activity. You'll see this attitude in operations departments or in places with lots of EE's who somehow ended up with software tasks. These places are 15-20 years "behind the times" as far as software development practice is concerned, they simply haven't gone through enough software projects to understand why sitting down and "cranking out" code can lead to deep problems. This problem has been accelerated by the introduction of RAD (rapid application development tools) that allow inexperienced people to get into coding on a very easy learning curve-- until they realize that RAD DOES NOT protect you from software engineering flaws.