The development of Solitaire Pack as part of this independent study has been significantly different than previous projects I've worked on for my own purposes. Also, it was quite a bit different than the project I helped create for Team Software Project (CS3141). This document will compare and contrast this project with these other projects I have worked on.

Compared to CS3141

Working simeotaneously on two large software development projects was a tremendous amount of work. There are ways in which each was "better" than the other, as far as ease of development and enjoyment are concerned.

Personally, I enjoyed being able to develop a Windows project and be able to take advantage of the years of experience I have in this area. Comparing this to Team Software Project, which was a Java program developed in a UNIX environment, I feel that the overall program quality is much higher in Solitaire Pack. However, being a Windows user, I am quite biased in making this assertion.

Developing software in a group was much different than I expected. After years of having no one of equal competancy that I could turn to, it was great to be able to get help and feedback from group members. If Solitaire Pack were designed and developed by more people than just myself, things that I didn't think of or problems that I didn't anticipate would be more likely brought forth in the group setting.

Not being responsible for the entire project yourself is both an advantage and a disadvantage of working in a group. I sure was thankful that someone else volunteered to write the file parsing component of our project. And, it was nice knowing that you simply didn't need to worry about certain parts of the program.

However, in working in a group, you must always make sacrifices to keep each group member adequately satisfied. In my group, for instance, one member felt the program was best designed so that every GUI element is always created, and simply shown or hidden when necessary. My personal opinion on this approach is that it is somewhat bloated and inefficient; however, it seems to make the program run faster. While having to compromise can sometimes lead to not being very happy with the design, it also allows you to learn from other people's ideas, something that would have been very helpful in a project of the magnitude of Solitaire Pack.

Compared to Independent Projects

The main difference between working on this project and several recent projects of mine is the amount of designing and writing of supporting documents that were part of this project. The first steps in this project were describing my goals in doing the project and detailing program features. In other projects, I would sometimes make a list of features, but never as detailed as this project's list. Granted, this project already existed in an old implementation, so coming up with a list of features was rather trivial. However, even when I add features to other projects, I usually don't write up anything about them.

The design phase of this project was also significantly different. While I would usually spend some time designing the overall architecture of a project, most of my actual designing would occur while I am doing the coding. Performing more detailed (but not as detailed as it should have been) designing using UML helped make the overall implementation much more straightforward.

One major way in which development of this version was easier than the previous version was in the use of my white-box components (bmws components). Basically, anytime I would create a piece of "general" functionality, I would put it into a separate file so that I could use it from multiple programs. In fact, it was in the latter stages of the old Solitaire Pack (before abandoning it) that I first started making these components.

These components encapsulate common tasks such as string manipulation, error checking, and COM component implementation. Looking back at the old code, I am sure it would be significantly easier to read and understand if it were simply designed using my new component framework.

The last major way in which this project was different from other projects is that I was accountable to someone to get stuff done. Previously, it would make no difference if I had an easy-to-explain architecture, as I would never have anyone I had to explain it to. I wouldn't have to worry about commenting my code extensively as I would know that no one would ever look at it.