Writing a blog for a blog

A while back I talked about our evolving blog world. To summarize, we've implemented an internal blog by scraping atom feeds from blogger. Google hosts the content and we read it and display it in our application so that the user experience is that the content is homegrown.

We added this project to the sprint and Crash and I specked it out via Google talk. This was a very high-level conversation and it was fun for me. I'm a visual guy and had to throw some stuff on the white-board for clarification but the bulk of the conversation and design were done over instant message. So, we truly have this mobile communication rocking!

The development vision I had:

Crash did the heavy lifting architecture stuff. Meaning it was his design and he defined what he wanted (strongly typed blog objects).

My job was to take that design and make it functional and that's what I did. A blog has a feed,  a feed has entrees. I wrote an atom parser (yeah yeah, we aren't on .net 3.5 yet), a blog datasource control and a blogliteral control (to give other programmers a drag and drop control example). The implementation is simple; drop a blogdatasource control and a blogliteral control on a page, set the literal datasource to the blogdatasource and bind.

The last step is implementation. Once the core foundation is complete, we can had it off to programmers for implementation. I like this concept for several reasons.

1) Another programmer is reviewing my code, even if they don't realize it. This can be very beneficial for the team. Think of it as pre-QA.
2) More than one person will understand its functionality on a technical level. This is important for me because as I get "drive-by's, I now have the ability to delegate to someone with experience on the project.
3) I get to move-on to developer tasks. Implementation is important, but the hard work is in the design.

Everything went great until it was time for implementation. We had delegated the implementation as a sprint item on a programmers list. Crash is very excited to show this feature off at an upcoming demo so he wanted it implemented as soon as possible. I think Crash realized, as anyone at his level would, that the implementation needed a trusted touch. So, guess who implemented it? Me!

I'll be honest; it was fun. To write a set of controls without the intention of implementing them yourself was different for me. I got to test my own programming skills which was super cool. So I created grunt work and I became the grunt.

I've always felt that the success of a new development project was determined by how many new changes are requested by the users. I'm talking about the "hey, this is cool. It would be really cool if you could also do this" type of feedback, not the "WTF, it doesn't work" feedback. This project is unique in that there is not a specific client that asked for the development; it was Crash. I sit next to him everyday so the feedback will be quick and relentless. Nevertheless, I know if I get "dude, it would be cool..." type feedback, this project, at all levels, was a success! Worst case scenario would be no feedback at all. In my experience this means no one gives a sh!t. I've had a few of those in the past...