This is a continuation from this thread Help Choosing The Correct UML Diagram (Beginner) . It seems like I cannot reply to it; it always send me to the first page when I try. Now that I'm done with my project, I have the following to say (long!). Fastlane69 you were right, I did blow off my leg! I started with the Use-case and the Sequence Diagrams. I really liked doing them because they helped me with emphasing on the clients' requirements and also depicting how the finished program "is going to" operate. They did blow up in my face though--more on this later. Then came the Class Diagram, and man that was a though cookie. At first, I started to think about all the classes that I would need, and how I would connect them together. I ended up with 3 base classes: 1 with 2 subclasses and another one with 3. Then came the nightmare, I couldn't connect them. I mean, could not reproduce the flow of my Sequence Diagram. I spent two days trying to fix it by either adding more classes or functions that would handle the other classes. Fed up, I took a two days break playing Megaman Zero 3. And one morning, while in the bus, it just "clicked". Literally, the clouds moved away and the solution appeared in front of me. I had too many classes... and after droping them one by one (it was a lot of fun actually), I was left with 1 class and 3 subclasses. I also reslized that my Sequence Diagram was poorly designed in the first place, hence all the trouble. Lesson #1 : The less classes the better.

Quote:Until you actually sit down and code out the project, you're not going to really be aware of all the little nuances.

So TRUE Clash. I got my confidance back because I though I had a good design (for my first try at least). But that saying put me back to reality real fast. All the nuances started to pop up one after another. I guess I was too focused on the high level stuff and when I got to the low level, the design was no help at all. The worst is, and I am sure of it, that some of them I would have been able to predict. For example, in one function, I was outputting and formating the result directly to a textbox. To realize that I would need that value later on. Sure, the solution is easy--return the value. But when the value is 10$ and you only need the 10, and you cannot change the value of the textbox, it's a pain. Time and effort lost! Lesson #2 : Never think your design is completed. So that's it. Although I wasted a lot of time, I did finish the project on time. I also have to say that Clash your post is very demotivating. I have read it at least 20 times and don't see anything positive. I didn't want to believe it back then, but your right. Now, that TDD seems interesting. I didn't look to much into it. It would be cool if you could elaborate on it. Darkneon

I second that motion. I find that the people that think Agile is a buzzword are the people that aren't willing to give up their old school way of developing software and are just dead set in doing things the HARD LONG way.

Agile, at its core, is a methodology that is Human-Based...ie it starts with the correct belief that you will NOT get something right the first time but through careful iteration, you will get something that was better!! This is in sharp contrast to the old school developers that is Computer-Based and who think that their first pass at code should be 99% correct and keep wondering "why doesn't that last 1% work? It should work!" and keep trying to pound a square peg into a circular hole :} LOL

Beside, Agile complements UMLs fantastically since drawing is a much more expresive and efficient way to communicate large complex ideas (all too common is soft dev).

Remember your two lessons, they will take you far. Especially with UML, it is easy to see when you are overwhelming your system and I suspect this will NOT be the first time that you will look at a UML diagram and have a eureka moment by merely subtracting one class...try to do that with procedural, non-iterative programming!!!!

Thanks guys for posting. I will first answer to Emmanuel Deloget comments.

First Comment: OK, I can't comment anything right or wrong on this one! I can't because I don't have enough knowledge at the moment. But I don't discard what you said, I'll just put it in my bag until reality proves me right or wrong. As a side note, I have read it somewhere (can't remember where) where the person was suggesting to put only the important classes in the diagram and to indicate that the other classes exist without including them.

Second Comment: Sure, it's like the saying that "perfectionists never finish anything", which I personally totally disagreed with. But that's not the point, the point is what Clash mentioned before "[that] until you actually start making the API calls and writing the functions, you can't know if your design is correct". Now, replace 'correct' with my 'completed'. Plus, I'll say that it's not when you start off writing the code that you'll catch a problem with you design. You can write out 3/4 of the program and realize that the rest is off or something is missing. That's why from now on I am going to go back and forth between my programs and designs.

Furthermore, I started reading "Test-Driven Development By Examples" and I am also reading articles by Martin Fowler.

I have a question about TDD. Lets say that my primary goal it to save time. Is using TDD going in the opposit direction? I mean if you test every 3 minutes, even if it is for 30 seconds, at the end of the week that's a lot of hours lost. It has become an habit since I started programming, and I found it to be the most time consuming part. Or is it an "in the long-run" thing?

Thanks
Darkneon

Quote:Original post by Darkneon
Furthermore, I started reading "Test-Driven Development By Examples" and I am also reading articles by Martin Fowler.

I have a question about TDD. Lets say that my primary goal it to save time. Is using TDD going in the opposit direction? I mean if you test every 3 minutes, even if it is for 30 seconds, at the end of the week that's a lot of hours lost. It has become an habit since I started programming, and I found it to be the most time consuming part. Or is it an "in the long-run" thing?

It's definetly something that doesn't pay off until the end of the project. You can test now, when the code is fresh in your mind and fixes are blatantly obvious, or you can test later, when you'll have to spend more time remembering what the code does, and then fixing it. Unit testing is orders of magnitude easier and more productive than intergration testing.

It also (at least for me) is huge morale booster. There are few things better than seeing all of your tests pass.

Whether it reduces development time is irrelevant to TDD - it's all about increasing the quality of the code. It usually taking the same amount of time as "traditional" testing methods, but produces much cleaner code. It's also a great way to debug designs - when you're writing your tests, the design's flaws are more apparent than when writing the actual code.

I'm getting confused here.

Quote:TDD essentially automates your debugging process. Rather than having to step through the code and place print statements everywhere, you automate the checks.

What do you mean by 'automates your debugging' and 'automates your checks'?

Quote:Which means that if you have already coded in the tests, then you've saved yourself from having to code in the tests on code that "works".

Let me try to rephrase it. If you have code that has been tested and debugged, now that it works, you don't have to modify it anymore? But working code is not shielded from future code.

Quote:However if you write the tests as you develop the code, then your coverage will be more complete.

You will be able to spot stuff that otherwise you would have missed. The questions: "I need to write a function that will ..." and "I need to test a function for ..." lead to different answers even though they imply (more or less) the same thing.

Good link by the way.