 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
|
|||||||||
| ||||||||||
|
||||||||||
| ||||||||||
|
||||||||||
|
Component Development Finals Summary
by MPhk
This was a considerable amount of work for the short period of time the competitors had, and every decision they made was critical to their final score. Each one of them tried to choose the enhancement they had found to be the easiest to implement, and consequently they all ignored the support for non-numeric statistics, which was likely the most difficult enhancement. oldbig and colau chose to implement the support for ZIP file expansion, while visualage, sindu, cnettel, matmis and arylio went with the command-line support for plug-ins. The ZIP file expansion support was a slightly more difficult requirement compared to the command-line support for plug-ins. The developers attacking this enhancement had some problems understanding and implementing it properly, basically because they made some wrong assumptions. In a normal competition, these questions may have arisen in the forums and would have been clarified by the designer, but now each competitor acted on his own and took the best decision for himself. Adding the command-line support for plug-ins was straightforward, and there were fewer problems regarding the implementation of the requirements. Nevertheless, this enhancement also had a tricky part - the modification of the state machine previously developed to count lines in a C-Style file to support the @-literal. Identifying the states and transitions would have been easier in a normal competition, where the public forum is used to discuss implementation details with the designer able to see what other competitors are thinking about, but in a finals competition finalists are not permitted to discuss their ideas. Reviews After the competition ended, the submissions were sent to the development review board for judging. TheCois (stress), cucu (accuracy) and MPhk (failure) had approximately 36 hours to score the submissions and determine the winner. In such a fierce competition every detail weighed a lot. Fulfilling the requirements of the enhancements was imperative, and most of the developers lost points in this section. arylio had some problems with the final fixes in the online round, and ended up with an incomplete set of deliverables in the onsite round of the finals. Repairing his submission instead of implementing the enhancement cost him valuable time, so he was not able to focus properly on developing and adequately testingthe required items. colau managed to implement the enhancement, but did not manage to develop any unit tests and test it properly. The lack of unit tests cost him some important points on the requirements side because of errors that were not identified by the developer, as well as on the unit testing side. matmis did not properly enhance his state machine implementation, and had a part of the unit tests missing. An incomplete set of deliverables cost him a significant amount of points. The other developers managed to fulfill the requirements of the enhancements at a higher level while also doing well in unit testing and documenting their final submissions. cnettel provided a complete and correct implementation of the requirements, but had problems in fully testing it . Also, his state machine enhancement could have been more clear and straightforward in several places. oldbig put in a good attempt in implementing the somehow more difficult enhancement (ZIP file expansion support), but he did not pay enough attention at recursive iteration of directories and lacked unit tests for minor functionality. sindu provided a correct implementation of the requirements and a good set of unit tests, covering all but one aspect of the component – some command line switches in the command line interface of the component. The submission suffered for lack of complete documentation for unit tests. visualage also fulfilled all requirements, properly enhancing his previous submission with the required functionality. The unit tests coverage on the component was complete, and the documentation was also well done, addressing all required details. The only downside to his submission was that some parts of the implementation could have been written in a simpler manner, but nothing critical. All submissions had their good and bad parts. Reviewing them was a challenging task. Even the smallest detailed counted a lot, and the smallest mistake could send one of the competitors to the bottom of the hierarchy. At the end of the review phase, the scoreboard looked like the following:
Appeals and Appeals Responses After presenting the developers with the reviewer scorecards, competitors had the chance to appeal any item that they felt was unfairly scored. The finalists had a limited 90 minute appeals phase to create and submit these appeals. When the appeals phase ended, the reviewers went over the scores one final time, reviewing and making any necessary changes. Most of the scores were raised, but the hierarchy of the finalists did not change much, only two developers switching places – oldbig and cnettel. The final score board looked like the following:
Congratulations to visualage for winning the 2005 TopCoder Open Component Development Competition! Congratulations to all developers that participated in this competition and good luck in the upcoming ones! |
|
