Multiple Room Chatting Application Help Request

[Innes Ford]

Hi coderanch!

This is my First post on coderanch, it seems to be a really friendly community. I'm a student at university with a piece of coursework asking to develop a chatting application in an OO language, as part of a reflection report on Agile development practices. I've chosen java because it's what I've been taught in a couple of previous modules. We were permitted to use generic examples of code already online as long as it was referenced, I found this one on this page at the bottom(http://cs.lmu.edu/~ray/notes/javanetexamples/) code is also bellow.

Anyway, the crux of my dilemma is that I'm quite weak at programming in general, hopefully this process will give me more ambition and enthusiasm to build my knowledge of Java and the Object Oriented paradigm of programming. I trying to use this code as a sort of spring board into what I've been asked to build in our client brief, where it was specified that clients could enter into private chatrooms, this example program only allows one room where all the clients talk when they connect to the server. I'm thinking that I could to cut and paste elements of this code into a separate 'room' class (I'm struggling to figure out in my head exactly which parts). I anticipate that there's going to be several things I need to change/add to such as buttons in the UI to open new rooms. I find all these tasks quite overwhelming and don't know where and how I should start.

One piece of advice, that one of the more mature students in one of my classes gave to me, was to make small changes, so that I would be able to know if and where things are going wrong. I'm struggling to think how I can do that here.

I've had a look at some of the other posts people have made on this forum and didn't find much useful advice, I am currently going through oracles custom networking trail I'm trying to wrap my head around how I should go about doing this and humbly request some general or specific advice on how I can or should efficiently approach this task. Please feel free ask any questions to satisfy any curiosity, I could honestly spew out loads of thoughts about this, I just have no idea how I should go about this project and organize said thoughts.

I can post the complete example code if needed, it seems I can't put it in a spoiler though so I won't for now.

Thankyou

[Campbell Ritchie]

Welcome to the Ranch
Please search this forum and this one because we get questions about chat rooms every now and again. They are not frequent, however. But I don't think chat rooms will be easy to program.

[Junilu Lacar]

Welcome to the Ranch, Innes!

You said at the very start of your post that you are doing this "as part of a reflection report on Agile development practices." Well, it so happens that Agile development is something very near and dear to my heart, so I'm going to focus on that instead of chat rooms.

One thing that Agile needs for it to have a snowball's chance is strong developers. Now, it doesn't need all the members of the team to be skilled and experienced but it can't function well without at least a few on the team who are. This is because Agile depends a lot on heuristics instead of prescriptions. The rules of Agile are more like guidelines really, and experience is needed to know just how and when a rule is to be applied and interpreted given a specific context.

Take for example the advice you were given to make small changes. This is in line with the Agile principle of incremental development. What's missing from that advice is the caveat that you need lots of good unit tests if you're to be successful at incremental development the way I think those people who gave you that advice had in mind. Also missing is the fact that you need a good, clean design that you already understand. If you don't have either of lots of good automated unit tests and a good, well-understood code base, then you have an uphill, no, an up-a-cliff, up-the-creek-without-a-paddle epic kind of battle in front of you.

Agile is not easy because software development, good software development, is not easy. If you are a babe in the woods when it comes to programming, I'm afraid you've just been handed the keys to an off-road vehicle for which it's going to take years of training and practice before you'll be able to drive it and get yourself out of the woods.

Sorry to paint such a bleak and unpromising picture for you but that's another thing that Agile brings: it doesn't help you solve your problems, rather it makes all your problems infinitely more apparent and painful so that you have to deal with them like a professional.

Good luck.

[Junilu Lacar]

Those who know me around here and know about my passion for anything and everything to do with Agile will not be surprised by this follow up because my previous response was just way too short (yeah, that was "short" coming from me about Agile).

Let me explain a bit about "heuristics vs prescriptions".  It all has to do with context.

Always consider context.

That's what Andrew Hunt wrote in his book, "Pragmatic Thinking & Learning: Refactor your Wetware".  Andy, the co-author of another book that's widely read and cited in the Agile community, "The Pragmatic Programmer: From Journeyman to Master," was one of the seventeen original signatories of the Agile Manifesto back in February 2001.

Experienced programmers can intuitively put a problem into context. That is, they can reach back into their stockpile of past experience and frame the current problem in the same context as some of the problems that they have worked on in the past. In doing so, they can start applying heuristics to "instinctively" know what to do next in attacking a problem.  Inexperienced programmers like you, by definition, don't have that vast pool of experience from which to magically pull context and apply heuristics. That's why they rely on what Andy Hunt refers to in his book as "context-free rules" in order to get anything done. The context-free rules or "prescriptions" give inexperienced developers "abilities" that they would otherwise not have without the recipes.

This is why inexperience and Agile are largely incompatible, because Agile is a set of guidelines, not prescriptions or recipes. You need experience and an ability to use that experience to put a problem into context. Without it, you're going to be literally a lone, blind sailor in a boat in the middle of the ocean without any means of navigating or finding a point of reference.

Again, sorry if this outlook is so bleak or even discouraging for you but I've seen this before and I hate that it often results in people getting turned off to Agile because they think, based on their sad experience with it, that it's a largely hype-driven, ineffective set of techniques. It's not but it's kind of like that saying that goes "You need money to make money," in that with Agile, "you need good developers to write good software and agile developers to do Agile development."

[Junilu Lacar]

Innes Ford wrote:One piece of advice, that one of the more mature students in one of my classes gave to me, was to make small changes, so that I would be able to know if and where things are going wrong. I'm struggling to think how I can do that here.

I know that I've said nothing so far that can be considered as encouraging for you. Not all hope is lost, however.

Here's what I would advise you, if you're comfortable with taking free advice from a complete stranger you've only "met" in a small corner of the Internet:

1. Get a more experienced programmer to work with you. Preferably, that programmer will have done some work in a real-world Agile project before. If for some reason you can't do this, you're in for a hard time.

2. Preferably, you would start by reading through the code that you have, understanding its design, and writing some tests that support your understanding of how the software works. If you are lucky, the code that you have chosen to start with is amenable to being harnessed to an automated unit testing framework like JUnit.  If not, then you're in for a hard time. If you can't tell the difference, then you're in for a hard time.

3. Preferably, you would have time to learn how to refactor.  Given that there are literally dozens of ways you can refactor, here are the Three Basic Refactoring techniques that I teach developers that I work with:

- RENAME refactoring - to make your program names meaningful and expressive of their intent

- EXTRACT refactoring - to eliminate duplication of knowledge in your program. This related to the DRY Principle of Design which stands for "Don't Repeat Yourself"

- COMPOSE METHOD refactoring - so that your methods maintain a Single Level of Abstraction and can aid in functional decomposition of the problem that you're attacking.

4. Lastly, buy the book by Corey Haines, "Understanding the Four Rules of Simple Design" -- it's what I've been recommending to all the developers who will listen to me to read. Anyone who would attempt to do Agile software development needs to read this book, understand it, and practice all the exercises and challenges given in it.  The book is available from LeanPub.com as a PDF download.  I'm not getting anything out of promoting this book—and believe me, I've been promoting it a LOT lately—I just think it's a phenomenally important book in getting more programmers to think about craftsmanship and the art of computer programming.

[Innes Ford]

The insight you've given me, Junilu, will be especially helpful in deciding the aspects of Agile I will focus on in my report. I'll be sure to emphasize unit testing, I suspect that is something I might have not given enough attention without your input. I can still reflect on failures of my project, as long as I give good reflection I doubt the penalization would be too significant, but it'd be penalized non the less.

Thank you both for the response.

[Junilu Lacar]

Innes Ford wrote:The insight you've given me, Junilu, will be especially helpful in deciding the aspects of Agile I will focus on in my report. I'll be sure to emphasize unit testing, I suspect that is something I might have not given enough attention without your input. I can still reflect on failures of my project, as long as I give good reflection I doubt the penalization would be too significant, but it'd be penalized non the less.

Thank you both for the response.

No problem, I'm glad you got something from the doom and gloom that I painted. One more thing I'd like to point out. Unit testing is important but it's not an end to itself. Unit testing is only a means to an end, which is UNDERSTANDING what the software does and what its interface should look like. It's a means of driving out the design flaws and bugs that are in your program. Bugs are manifestations of a FLAWED UNDERSTANDING of how the software should work vs how to tell the computer how you want the software to work. To truly understand your software, you need to be aware of things like code smells and refactoring and good software design principles.

Unfortunately, these are the kind of things I find that relatively few programmers pay much attention to with the vast majority considering them less important than say what are the new features in the latest version of Java or what are the cool things you can do with functional programming languages, or what are the new features of the most recent release of the Spring Framework. Most programmers chase whatever is the "new shiny thing" that's all the rage these days. But the good programmers know that for longevity and true skill and ability, you need to know and master the basics and you have to stick to good programming principles. Without good fundamentals and solid understanding of principles, everything else is just fleeting and subject to obsolescence.

As such, Test-Driven Development (TDD) is an extremely important part of Agile software development from a programmers perspective. I always find it suspicious when teams claim that they are doing Agile software development and yet don't do pair programming (always writing production code in pairs or groups) and TDD because these, IMO, are cornerstones of a good agile technical practice. They are techniques that help you go back to basics and good, sound design principles. I could spend another thirty minutes telling you about TDD but if you're curious, dig around in the Engineering section of forums on this site and find my previous posts about TDD. You might even find some posts where I walk through the process of doing TDD, refactoring, thinking about and applying good design principles, and writing unit tests. Fair warning: those threads are quite long and are not for the easily bored and distracted.

If you want to post some code and get a taste for what it's like to do TDD, refactoring, and design, feel free to post it and I'll be happy to walk you through the process and hopefully give you a little bit of context that you can use later on.

[Junilu Lacar]

I went ahead and took a look at the code that you posted a link to.  I recently wrote an TicTacToe implementation in Java, spurred by a question posted by one of our members.

Here's some code that was on the site that you linked to:

    public boolean hasWinner() {
        return
            (board[0] != null && board[0] == board[1] && board[0] == board[2])
          ||(board[3] != null && board[3] == board[4] && board[3] == board[5])
          ||(board[6] != null && board[6] == board[7] && board[6] == board[8])
          ||(board[0] != null && board[0] == board[3] && board[0] == board[6])
          ||(board[1] != null && board[1] == board[4] && board[1] == board[7])
          ||(board[2] != null && board[2] == board[5] && board[2] == board[8])
          ||(board[0] != null && board[0] == board[4] && board[0] == board[8])
          ||(board[2] != null && board[2] == board[4] && board[2] == board[6]);
    }

Some programmers will look at that and sit there and try to figure that out. I will often tell people that code like this "defies understanding".  I mean, I have an idea of what this code is trying to say but I have no way of looking at the code and immediately saying, "Yeah, that looks like it's doing the right thing."

That's not Agile.

In contrast, here's the code that I wrote that's related to the same problem:

private boolean noWinner() {
	return !gameWasWon;
}

private void checkForWinner(Position spot) {
	gameWasWon = wins(inRow(spot.row)) || wins(inColumn(spot.col)) || winsInDiagonal();
}

This code says "There is no winner if the game hasn't been won yet. We can check for a winner by looking at whether a move made in a given spot results in someone winning in the row that includes that spot, or in the column that includes that spot, or in one of the diagonals on the board."

Now, that's what REFACTORING - Rename, Extract, and Composed Method gives you: A good understanding of what your software does and a confidence that what you're telling the computer to do is actually what you can expect it to do.

[Junilu Lacar]

And here's the code from that other site that uses the hasWinner() method:

        /**
         * Handles the otherPlayerMoved message.
         */
        public void otherPlayerMoved(int location) {
            output.println("OPPONENT_MOVED " + location);
            output.println(
                hasWinner() ? "DEFEAT" : boardFilledUp() ? "TIE" : "");
        }

        /**
         * The run method of this thread.
         */
        public void run() {
            try {
                // The thread is only started after everyone connects.
                output.println("MESSAGE All players connected");

                // Tell the first player that it is her turn.
                if (mark == 'X') {
                    output.println("MESSAGE Your move");
                }

                // Repeatedly get commands from the client and process them.
                while (true) {
                    String command = input.readLine();
                    if (command.startsWith("MOVE")) {
                        int location = Integer.parseInt(command.substring(5));
                        if (legalMove(location, this)) {
                            output.println("VALID_MOVE");
                            output.println(hasWinner() ? "VICTORY"
                                         : boardFilledUp() ? "TIE"
                                         : "");
                        } else {
                            output.println("MESSAGE ?");
                        }
                    } else if (command.startsWith("QUIT")) {
                        return;
                    }
                }
            } catch (IOException e) {
                System.out.println("Player died: " + e);
            } finally {
                try {socket.close();} catch (IOException e) {}
            }
        }

See if you can find where the two references to hasWinner() are in less than 5 seconds. I bet you can't. I don't know how to begin "talking my way through" that code. The above code does not have a Single Level of Abstraction and it again "defies understanding".

On the other hand, here's the code I wrote that's similar in purpose to the run() method in the above code:

private void play() {
	System.out.println(currentPlayer + " goes first.");
	drawBoard();

	while (currentPlayer.moves() && gameNotOver()) {
		currentPlayer = otherPlayer();
		sayWhoseTurnItIs();
	}

	announceResult();
}

private boolean gameNotOver() {
	return noWinner() && hasAnyOpenSpot();
}

private boolean hasAnyOpenSpot() {
	return hasOpenSpot(inRow(0)) || hasOpenSpot(inRow(1)) || hasOpenSpot(inRow(2));
}

1. Play starts by announcing which player starts first, then drawing the board in its current (empty) state.

2. While the current player makes his/her move and that move does not result in the game being over...

3. Players switch roles, i.e. the other player now becomes the current player.

4. Display the updated board that contains the most recent move made whose turn it is to move now, then go back to Step 2. (Edit: actually, the call to display the updated board is done as part of the current player making a move, which is invoked by currentPlayer.moves())

5. When the game is over, announce the results.

We determine that the game is NOT over when: There is no winner AND there is still an open spot left on the board.

We determine that there's an open spot left on the board when:  there's an open spot in row 0, or in row 1, or in row 2.

That hasOpenSpot() method is a little ugly but since there are only three rows I need to check and the method only has one line, it's not too "smelly" to me.

You hardly ever see programmers go to the kinds of lengths it takes to write code that is this clear and succinct. Maybe 90% of code written out there and thus, 90% of programmers out there,, write code that "defies understanding" like the code that you linked to. It's not terrible code. In fact, by most measures, it's pretty decent code. It's just not code that a truly Agile developer would allow to slip by without some ruthless refactoring first.

[Junilu Lacar]

The point of showing you these contrasting examples of code is this:  

You can't easily understand code that defies understanding.  To make code easier to understand, you need to refactor to clarify, simplify, and decompose. To refactor successfully, you need to write unit tests that will tell you when you've broken something when you made a change. To write tests, you need to UNDERSTAND what your code does. Now, go back to the first sentence in this paragraph.

Code that defies understanding creates a vicious cycle.

Code that promotes understanding creates a virtuous cycle.

Agile Agility in software development means using a set of techniques that encourages the creation of virtuous code and the elimination of vicious code.

[EDIT: I promised myself earlier this year that I'd stop using "Agile" as a noun and I often fail to keep that promise—it's much better and more productive to think about "being agile" instead of "doing Agile"]

[Junilu Lacar]

And I admit, even I can run out of steam and miss that one more refactoring step to bring everything in my methods to the same level of abstraction. That play() method could be refactored one more time to this:

private void play() {
    sayWhoGoesFirst();
    drawBoard();
 
    while (currentPlayer.moves() && gameNotOver()) {
        currentPlayer = otherPlayer();
        sayWhoseTurnItIs();
    }
 
    announceResult();
}

private void sayWhoGoesFirst() {
    System.out.println(currentPlayer + " goes first.");
}

*Now* the play() method has a Single Level of Abstraction!

[Innes Ford]

Junilu Lacar wrote:
Code that promotes understanding creates a virtuous cycle.

Agile Agility in software development means using a set of techniques that encourages the creation of virtuous code and the elimination of vicious code.

That conclusion was very satisfying to read. Thank you so much for this bit of evangelism, you've shown me an extremely well thought out approach and way of seeing the programming profession, I like the way you've expressed a preference for the idea of 'Programming Agility' over 'Agile Development' it's far more interesting way of thinking about the ideology.

I wish I had come to this forum sooner and found such inspiring views and ideas. I feel like I could go on a big moan about how let down by my university I've been, but have repeatedly told myself that the responsibility has been on me to find inspiration, it seems I finally got round to it.

I've come across the idea of the vicious cycle before, but never thought to imagine it being applicable to programming.

Ideas like Single Level of Abstraction, Don't Repeat Yourself (I remember my first high school computing teacher giving a little lecture on an idea in this vein), Keep It Simple Stupid, are precisely the things we should be  being taught as soon as possible. These ideas are what seem to be the justification of using object-oriented design, you've demonstrated perfectly that it's far easier to understand the program and thus learn from a program that has been written by your example than the other that I had found.

Ideas of technical debt and the vicious cycle must certainly apply when educating people just as much as the your virtuous cycle. If more people saw it this way, maybe there'd be more adept programmers.

I'm truly grateful for the time you've spent writing those posts and giving your example code, you've imparted more wisdom than most of my lecturers have in any of their lectures, they usually just copy from online tutorials anyway.

[Junilu Lacar]

You just mentioned "Technical Debt" and "vicious cycle" in the same sentence. I'd also point out that Technical Debt, or more appropriately, The Debt Metaphor, was meant to be a Good Thing™. Search YouTube for "Ward Cunningham explains the Debt Metaphor" and listen to the person who coined the term explain what he really meant by it.

[Campbell Ritchie]

Junilu Lacar wrote:. . .  I recently wrote an TicTacToe implementation in Java, spurred by a question posted by one of our members. . . . "defies understanding".   . . .

That is the sort of code you get when people don't think about the rules of the game. Had there been any thought put into that noughts and crosses (=TicTacToe) program, the user would have realised that you only have to check more than three directions in one specific circumstance, and that you only have to start the check from a single square.

[Junilu Lacar]

Campbell Ritchie wrote:you only have to check more than three directions in one specific circumstance, and that you only have to start the check from a single square.

Yes, and that's exactly the idea, which by the way *did* come from you in the other thread, that is reflected in that single line of code in the checkForWinner() method that I, no, you and I, wrote.

[Junilu Lacar]

I'm not ashamed to admit that my first implementation of the checkForWinner method had the same kind of brute force approach as that large block of hard-coded expressions that defies understanding. The only difference was that I was using a couple of for loops to do it instead. I was still checking the entire board, however. When Campbell posted a comment that you only need to check the row and column in which the last move was made, that little bit of better understanding of the problem allowed me to see a way to simplify the check and make the code express that idea.

That's what pair programming / group programming can get you: a richer, fuller understanding of the problem because you have multiple perspectives of the problem and those perspectives can converge into a shared understanding that can be reflected succinctly and clearly in the code. It doesn't happen automatically though; successful pair and group programming takes a lot of effort. When it does succeed, however, the results are often nothing less than stunningly beautiful code.

[Junilu Lacar]

And successful pair and group programming is extremely righteous. Not only can it result in beautiful code and a shared understanding of the solution, it keeps spreading goodness by way of a better rapport among team members, joy and enjoyment in the team, people learn new techniques, gain more insights, amass more experience, ... I could go on and on about all the good things that come out of a good pair/group programming session.

[Junilu Lacar]

I can just imagine a conversation between a pair of ruthless refactorers who look at that one line of code in checkForWinner():

RR #1: "That kind of looks good. I mean naming those methods "inRow" and "inColumn" really helps make the calling code become more conversational."

RR #2: "Yeah it does, I thought that was a great idea, but... ?"

RR# 1: "... but that spot parameter name doesn't quite capture the idea we were talking about, which is that you only need to check the row and column where the last move was made. There's something missing in that name that makes it fall a little short."

RR #2: "You're right. So, why don't we just make the code say what you just said." (Quickly refactor-renames spot to lastMarked)

Both RRs read the new code out loud.

private void checkForWinner(Position lastMarked) {
   gameWasWon = wins(inRow(lastMarked.row)) || wins(inColumn(lastMarked.col)) || winsInDiagonal();
}

RR #1 & RR #2: "Brilliant! That captures our thoughts perfectly!" (Fist bumps and high fives)

This is what people miss when they only get their understanding of pair and group/mob programming from dry, technical descriptions of the mechanics of the technique. They don't and can't get a taste of the rich and interesting conversations that characterize good, effective, and productive pair/mob programming encounters. It's one of those "you had to be there to really appreciate it" things. Unless, of course, you can "feel" the conversation that I just narrated from where you're sitting right now.

[Junilu Lacar]

Even that narrative was considerably cleaned up. The full conversation, if I were actually having it in real time, would go more like this:

RR #1: "... you only need to check the row and column where the last move was made ..."

RR #2: "... So, why don't we make the code say what you just said." (Quickly refactor-renames the parameter name from spot to whereTheLastMoveWasMade)

RR #2: "How about that?"  (makes a face )
private void checkForWinner(Position whereTheLastMoveWasMade) {    gameWasWon = wins(inRow(whereTheLastMoveWasMade.row)) || wins(inColumn(whereTheLastMoveWasMade.col)) || winsInDiagonal(); }
RR #1: "Now you're just being a smartass."

RR #2: "What? That's what you just said, isn't it?"

RR #1: "Yeah, but that name's over the top. It's a bit of a mouthful, too. Just a little too conversational, don't you think?"

RR #2: "Relax, it's just so we can actually see it and feel how much it's NOT what we want to leave in there."

RR #1: "Hey, don't we have a mark(Position spot) method?"

RR #2: "Yes, in fact, we do. That's where we got the name "spot" to begin with."

RR #1: "Well why don't we just make the name we use here consistent with that term, of "marking" a spot? When we say "spot" over here, we really mean "the spot that was marked last," don't we? I think that was the missing part of the thought behind just "spot", right?"

RR #2: "So you mean to say you want to name this parameter like this? ..." (Quickly refactor-renames whereTheLastMoveWasMade to lastMarked)
RR #2: "Let's see what that sounds like now..."

(Both RRs read the new code out loud)
private void checkForWinner(Position lastMarked) {    gameWasWon = wins(inRow(lastMarked.row)) || wins(inColumn(lastMarked.col)) || winsInDiagonal(); }
RR #1 & RR #2: "Brilliant! ... "

That last part where RR #2 says, "Let's see what that sounds like..." is why I always insist that we read our refactored code OUT LOUD during pair/group programming sessions. Hearing your code read out to you helps you really understand whether the code you wrote is as expressive as it could be.

This type of thing can be done when programming solo, BTW, and I think I just gave you all a glimpse of what goes on in my home-office when I have nobody to do pair/mob programming with besides Go Gopher, Darth Vader, Chewie, and Boba Fett.

[Junilu Lacar]

I wrote:... in my home-office when I have nobody to do pair/mob programming with besides Go Gopher, Darth Vader, Chewie, and Boba Fett.

What I was talking about, in case you're wondering WTH...

[Liutauras Vilda]

Innes Ford wrote:I wish I had come to this forum sooner and found such inspiring views and ideas.

Me too.

I think Junilu deserved some cattle for advocating, teaching and defending when it's necessary his ideas and principles.
We don't have a lot members on Ranch who are such supporters of clean code. Thanks for being around

[Junilu Lacar]

Chewie was complaining that my inRow() and inColumn() methods were too goofy. He suggested I shift the "in" out of the parentheses and attach it to the "wins" name instead. I think I'll let the Wookie win on this one... besides, the big walking carpet does have a good point:

private void checkForWinner(Position lastMarked) {    gameWasWon = winsIn(row(lastMarked.row)) ||                 winsIn(column(lastMarked.col)) ||                 winsInEitherDiagonal(); }
That change actually made me make another part of the code nicer, too:

private boolean hasAnyOpenSpot() {
	return hasOpenSpotIn(row(0)) || hasOpenSpotIn(row(1)) || hasOpenSpotIn(row(2));

// Used to be:
//	return hasOpenSpot(inRow(0)) || hasOpenSpot(inRow(1)) || hasOpenSpot(inRow(2));
}

Righteousness and the virtuous cycle in action.

[Innes Ford]

Have you got a github, Junilu? I'd be very interested in seeing the complete code for this program you've written.

It's been amazing to witness the satisfaction someone gets from programming, how it motivates them to keep improving their creations, regardless of the eccentricities. It really is regrettable that I didn't visit this corner of the internet sooner, I fell into some comparatively bad habits (I wouldn't call them vicious, certainly vices though) like poker and chess, and spent too much time on these unproductive sources of satisfaction. I suppose I might not have been ready to change my attitudes for the better back then.

[Innes Ford]

To move the conversation closer to the original topic, what are your experiences of the design and planning process. You briefly discussed your ideas about the intuition experienced programmers develop, but I struggle to believe it's completely intuition when they take a more deliberative approach for larger, more complex systems. I'm required to create some UML diagrams for the application and include them in the report, would agile programmers still utilise UML?

One of the hurdles that gave me apprehension when starting this project was getting the planning right, my inexperience in implementing plans gets me anxious and I tend to procrastinate, I've no doubt the process of planning is extremely helpful in learning to program and anticipating the problems and their solutions of a projects implementation but, unfortunately, that knowledge doesn't really help motivate me.

If I make a plan that I have confidence in I'm sure I'll be much more efficient in more approach and journey to completion, and it's the inefficiency that pushes me to procrastinate, I'm a perfectionist that doesn't have the drive to be perfect, so I end up looking for distractions. I hope that makes sense. Anyway, do you have advice that you could give to a beginner about being efficient in the planning and development of a project, or is inefficiency something I should just work to come to terms with for the beginning of my learning?

[Junilu Lacar]

Innes Ford wrote:would agile programmers still utilise UML?

I supposed those who are comfortable with the notation could and do. I don't think they would do them in Visio or some tool that makes elaborate UML diagram. Whiteboard with a camera to keep snapshots of various things they try would be the extent of formality that I'd expect from veteran developers who practice agility.

Scott Ambler has some simplified UML notations at agilemodeling.com

I recently posted a reply giving my opinions about using UML diagrams. Here's the thread: https://coderanch.com/t/672716/java/convert-UML-diagrams-Java-code

Basically, I would just come up with a rough idea of a design to start with, write tests and code it out, even just roughly, then use a tool to generate UML from the codebase that I have designed, if I really need to. The formal UML documentation comes after the fact and is generated based on the actual code that I designed and wrote, not the other way around.

[Junilu Lacar]

Innes Ford wrote:One of the hurdles that gave me apprehension when starting this project was getting the planning right, my inexperience in implementing plans gets me anxious and I tend to procrastinate, I've no doubt the process of planning is extremely helpful in learning to program and anticipating the problems and their solutions of a projects implementation but, unfortunately, that knowledge doesn't really help motivate me.

If you constantly wring your hands and pull your hair about getting your plans right, you'll never get anything done except rub your skin raw and make yourself bald. Any good war story/movie/book will tell you that a good warrior/soldier/combatant is one who accepts that he's already dead before the battle even begins. Only then can he operate effectively (it's one of the great lines from "A Band of Brothers"). Even the best laid plans never survive first contact with the enemy.

Good developers know that their plans are subject to change. We're not psychics. We can't predict the future. There's always something that will come out and screw up our plans, things we did not foresee, anticipate, know about, or even imagine was possible. Murphy's Law is the bane of a developer's life. Development is a constant adventure of discovery and adjustments. That's why a mindset that's geared toward agility is the best way of surviving and still have a chance at coming out on top.

[Junilu Lacar]

and it's the inefficiency that pushes me to procrastinate, I'm a perfectionist that doesn't have the drive to be perfect, so I end up looking for distractions. I hope that makes sense.

I think it does. I used to be that way, in a sense. I still chase that perfect line of code whenever I can but I've also learned to move on with "just good enough" even though a lot of people will say my "good enough" bar is set pretty high.

That said, there's much to be said about knowing just what the heck you're doing. There are things that hardly ever change. Those are the basics and the principles. Like I said before, if you know those and have a good grasp of how to apply them in different situations, there aren't that many situations you'll run into where they will fail you or at least be the sole reason for coming up short. It's always something else. Basics and principles always form the solid foundation for me and it's the base that I can go back to when everything else is falling apart.

Incremental and iterative development goes hand-in-hand with incremental and iterative planning. Daily scrum standup meetings are planning meetings, not status meetings. TDD and the Red-Green-Refactor cycle, done every few minutes (2-3 if you're really good at it) is a short planning/testing/designing/refactoring cycle that developers repeat over and over again throughout the course of the day to try to quickly discover all the unknowns about the software that they're developing and keep their current understanding in synch with the software they have developed so far. If you think about it, the TDD cycle is a microcosm of the agile software development management cycle.

Like I said before, you need to partner up with someone who is stronger at programming than you are. You can't learn this all this stuff in two weeks (that's how long you have to get this project done, right?) but you can't let that stop you from trying either.

So, plan out the next two weeks: What features do you think are the most important to have in this Multi-room Chat Application? How do you break those features down into chunks of work that you can attack on a one-chunk-one-day basis?  If you do one-chunk-one-day, how many hours is your "day" going to be? How many hours are in your "ideal engineering day"? For professional developers, that's usually 5 hours of productive work. If you can only get 3 hours of productive work done per day, every day until your project deadline, then you should be able to get a sense of how much room you have in your schedule to fit the work into.

Prioritize your list of features by value and assess how feasible it would be to develop and finish. Make sure your features are just big enough for you to be able to complete development of any one of them in a day or two. Then go and pick one off the top of your list and start working on it. If you get done in a day, great. If not, you need to do some re-planning. Even if you get done with a feature in the time you plan to get done with it, you still have to reassess your plan each time you finish a feature and take a fresh look at the features still left on your backlog. In working that a feature, it's inevitable that you'll discover something about your system that you didn't know before and that new knowledge usually affects how you deal with the other features that you still have left to work on.

Reassess your plan and your feature list. Ask yourself what's the next most valuable feature you want to work on? Take it off of your backlog and get cracking on it.

Then you just keep iterating over that whole process of plan-execute-assess-replan-execute-assess-replan-etc. until you get to the day of your deadline.

Hopefully, throughout this whole process and starting from the very first feature that you implemented, you will have created a core nugget of working software that you slowly build on and grow as you keep working on new features and adding them to your software. If you do rigorous and disciplined testing and refactoring all throughout, you will get to the deadline with software that more or less works as you intend for it to work.

All these are the heuristics I spoke of before. It may read like a recipe but that's only because I can't put arrows and conditionals in prose like this. The reality is that there are a lot of those all throughout the process and it's impossible for me to describe them all and still stay coherent. You just deal with eventualities as they come up and make the necessary adjustments.

Anyway, this is getting really long so I'll stop here and let you process that for a while.