Sometimes building software is ugly. There, I said it. Sometimes, especially at the beginning of a project that will result in a new system, especially when you are working with a new (to you) software paradigm, especially when you are working with a new team, building software is ugly.
I recently was part of a project which took an existing piece of software on one platform, with the intention of re-implementing it on a new platform. Perhaps the biggest challenge came from the fact that the technical architect or lead who had been instrumental in developing the original product, and who was familiar with both paradigms, defected from the project when we were preparing to start the re-implementation.
He had been the driver of the decision on the new paradigm, and it was on the basis of his capacity that we built estimates and plans. Without him, we had to hire resources to work in the new paradigm, and find a leadership paradigm that could move forward.
While the new team was forming, and the new leader was coming up to speed, we started an iteration 0 to build out new infrastructure, and then an iteration 1 building a walking skeleton. I had hoped that this would help the team form, and practices would be established. Without the right leadership in place, things were ugly. Decisions were not made in the right sequence. One of the managers involved in the project said:
