I've been working on Beth's website over the past few months. I find the easiest way to work through building the logic is to leave the views empty in the controller, and work with the web2py debug view to get the locals(), when this is working, I can move on to the next step. I find I'm making a few temporary lists to hold intermediate results, and inspecting. The web browser is a pretty useful tool for what' essentially printf debugging. I haven't used the other debug tools much, but I think the tickets (unless the model gets so wrong the tickets won't load) are a good way to return to a stack trace, and present both a developer view of open issues, and allow the user to forward a link to the website.
I had initially been working live, which was nerve wracking when the changes would break a migration and take down the site. I think having many controllers is better for small local changes, since broken code in the same file can prevent interpretation. I might have structured this differently if python could ignore some blocks...
I just wish that the wsgi setup on cpanel servers weren't so counter-productive. I currently have a cron to ensure the socket is owned by the site user, since it defaults to root/nobody, and under cpanel's configuration (maybe this is suexec related), the account doesn't have access to the wsgi server.
