"Thrashing" is unproductive or wasted work, including rework. Thrashing has many causes, including unclear communication, poor planning, lack of defined processes, and inattention to quality.
Here are some examples contributed by CPE 205 students at the end of their course.
Requirements
On the SRS, we did parts of it individually without any standards and integrating and numbering it was unproductive.
I spent 3 hours or so on trying to get my test cases to work. The whole time I could not figure out why they kept failing. I later found out that in the specification, a feature was poorly explained and after that, I fixed the problem in 5 minutes.
Developing a program without consideration of the customer’s requirements led to unnecessary programming hours
Documentation Standards
When people didn’t put commenting in their source code, and had to go back later to figure out what comments and other documentation should go where in the source file.
One person wrote most of code. Took forever to make it conform with coding standard.
Writing javadoc comments without fully understanding everything that was needed to go into them (not detailed enough). Reworking documents because we hadn’t reviewed the QA criteria ahead of time.
Writing comments in my code in the finding out that they were not javadoc comments and having to go back and edit them all.
I spent time on pseudocode and found out I had done it completely wrong. So I had to have a fellow group member help me to redo it all. We ended up spending too much time reworking it when we could’ve been doing something else.
Design
In 205 last spring, our team did not have a good method of keeping track of the decisions we made. So, in the beginning of the designing phase, we designed the whole architecture of the software and made many small and big decisions. But, we did not keep track of most of them. Then, in the detailed design phase, we spent more time discussing and making those same decisions over again.
In CPE 205 I felt like I was thrashing when writing the class headers for the high level design. I was writing issues about my classes while team members were writing about the same issues for their classes. We should have all made an issues list for our classes, combined them all together (deleting duplicates), and written issues list then.
We didn’t spend enough time working on our design. We ended up throwing it together in a rush. By the time stage 1 implementation came around we were so busy redesigning on the fly that there was little time to code. We spent hours in team meetings arguing over what to do. When the deadlines hit, only a few of us were able to work on the code. Everyone else was too confused.
Our team was trying to create the architecture of our project while simultaneously making other artifacts, such as the Interaction Diagrams. However, this was most unproductive, in that the architecture changed at least 10 times, resulting in reworking then Interaction Diagrams with every change.
Writing classes before design was complete and then having to go back and change and redo many classes in order to fit the new model.
The first time through the D-Requirements, the data dictionary was a mystery and turned out to be a mess. We did not understand first all it required and later how we could have known every data field before the design. After the design, we redid the data dictionary and it turned out well.
Configuration Management
The biggest thrashing experience I had personally in 205 was fixing the dozens of random errors in my team members’ Java files when trying to compile the whole Javadoc package. It was even worse thrashing when I had to do this a second time because of versioning control problems, when my changes got discarded.
Created a draft of a document in lab, forgot to email that version to work on it at home, so we had to recreate it all again (30-40 min of wasted work).
We had so many versions of class diagrams, they all got mixed up. Javadocs got all mixed up. We had copies of our source codes all different versions at random places in directory structure.
At the last minute before delivery we had a version control problem with our Together class diagram. We spent half an hour correcting it.
SRS not latest version for everyone- had to get latest first. Not having latest code didn’t know what had to be done until the end. Surprises of all kinds. Not having latest diagrams. Not knowing who had the latest.
Trying to get 2 different modules to work together before Stage 1 Implementation. Spending time debugging since wrong version of class being used instead of current version.
Group members didn’t communicate well enough about who was going to do what, and 2 of us ended up coding the same thing.
Ineffective meetings
Wasting time working on something that can be done by an individual instead of the whole group. Time can be spent more productively if we distribute trivial tasks that don’t require the whole group presence to a certain few. While the others can work on something else.
Thrashing occurred in our project when we had a team meeting to discuss design issues and after over an hour of discussion and proposed changes we came back full circle to the design plan we had started with.
Our team had a lot of long meetings outside of class in which not everyone always had something to do at that moment so they were waiting for someone else to finish things. Although we got the work done that needed to be finished, we really shouldn’t have needed to all be at such lengthy meetings. There was too much time spent idly waiting.