MessageBoards will provide board, forum, thread, and post-level functionality we have all grown to love–yet in the context of our academic portal tied into roster info.

I’d like to approach the way I code this tool differently, specifically:

• Introduce month-long design/code/QA iterations.
• Unit & integration testing.
• Create a good set of Selenium tests.
• Use the Doctrine framework for the underlying model.

Why bother changing the approach? We could code this tool just fine without changing the process, adding automated tests, and changing the framework.

MessageBoards is a big experiment. It may actually take longer to develop (although I hope not)–and it will give us a lot of good feedback on some new web development approaches that promise to reduce time to delivery. Delivering results faster–and with similar quality–would be a huge win.

There are a lot of variables in play, like the percent of time I dedicate to MessageBoards, and the four new approaches mentioned above. In the end, I anticipate it will be a challenge to isolate which variables added or removed value.

Another couple variables I bet will reduce time to delivery: working in parallel with a talented UI designer and the excitement of possibly finding something that will make other programmer’s lives easier.