See all Work History & Feedback
Related links:
The majority of my time at ThoughtWorks was spent working with an agile team of about 40 people, including ~7 pairs of developers, on an enterprise-level auction site. The site, which replaced an existing ASP.NET app, received many accolades from the client due to improved performance, reliability and malleability. I left when the team was scaled down because the client could not get new feature requests approved fast enough to keep the team occupied.
Our code featured extensive test coverage, integration with .NET and Java applications via web services and shared databases, a separate deployment application, extensive redundancy, health and log monitoring. The team also added several components unusual for Rails, including multiple databases, scheduled workers, mongrel handlers, and web services. My biggest contributions were a mongrel handler integrated tightly with Apache for optimized image scaling, increasing relationships with the level 2 techs for a better production support process, and simplifying existing class interfaces.
I enjoyed working with Matt but found the development environment painful. The dev server experienced myriad random problems. Sometimes it was unclear whether I had caused the problem or whether the server was just confused. The Rails project had been bastardized so much by the variety of developers who worked on it that I found myself spending 20 minutes trying to figure out what view or model to use, something you would expect to avoid on a Rails project. In fact, the reason that it is necessary to work remotely with this project is that the project is held together with (metaphorically speaking) toothpicks and some chewing gum, and ( according to Matt ) getting it to run on developer's machines is very, very difficult. These are the sorts of worrisome things that Rails tries to avoid.Another issue with the working environment was that I was not able to commit to the repository, and my code was never brought into sync, so I was constantly concerned that things might work for me but not on the server. Matt's response to this seemed to be that he didn't want to spend any time fixing things because the clients didn't want to pay for it. I can respect that position, but it didn't make the process feel any smoother. In turn, this made it difficult to want to work on the project.As I said earlier, I found Matt to be a very pleasant and reasonable person, and enjoyed working with him.
