Looking Back On The Last Project
Posted by Davy Brion on September 16th, 2008
It’s always interesting to look back when you’re finishing up a project. This was my first project since moving from working at clients to working at our own office. We wanted to make some changes in our way of working so we decided to use some of the wacky ideas i’ve posted on this blog for this project. More specifically, we used the Request/Response Service Layer and my MVP approach for writing testable ASP.NET Web Forms.
The first 2 weeks were a bit rocky since the other developers had to learn about Dependency Injection, Inversion Of Control and using a mocking framework for most of our tests. In the first 2 weeks, we didn’t reach any of our time limits, but then again, we expected that because we knew it would take some time to get used to all of these new things. I actually thought it would take 3 weeks before we would start getting up to speed properly. Luckily, the other developers caught on pretty fast and before we knew it, we started beating the time limits.
Obviously, we did our weekly retrospective after each sprint, and i was particularly interested in how they felt about working according to these new concepts. For the server-side implementation of the Request/Response service layer, i didn’t hear a single complaint. Once they got used to it, they seemed very comfortable with the whole Request/Response thing and i think they really liked how the Inversion Of Control container just ‘magically’ wired everything up. For the client side Dispatcher (used to send Requests and fetch Responses) there was one complaint about having to explicitly clear the state if you had to make 2 trips for some reason. Now, the complaint was actually made because i changed the behavior in one specific case after a few weeks, which broke a few screens, so their complaint was definitely justified.
Another complaint that i heard twice, was that the tests for the Controllers of the Web Forms could get pretty complex or even annoying once you had to deal with complex screens. We never really found a way to make that easier, and i don’t really think it can be made easier, to be honest. Complex screens simply require a lot of testing. There’s not a lot you can change about that. I definitely prefer writing a bunch of tests over testing it manually all the time. Having said that, it’s still important to keep in mind that screens still need to be tested (thoroughly) manually from time to time. No matter how many tests you may have, they simply don’t cover everything that happens when a user is actually using it in a browser. By the way, i think i was the biggest offender of this rule.
So how did we do? The project is pretty much finished now… one team member is still working on the project to wrap it all up but he’ll probably be finished in a few days. We stayed under budget, and the issues that were reported by the project leader (who’s also playing the customer proxy role) were all fairly minor, a lot of them related to stupid UI issues. I think most of the issues were related to my total lack of solid ASP.NET knowledge actually 
I’m also very proud of the overall quality of the code base. Everything is very readable, simple and flexible while there’s nothing bad hidden in there. It’s actually the first time in my career where i felt this way about a code base where i didn’t write the whole thing myself 
Oh and to Joel and Sacha: thanks for doing a great job