While helping with the content for our DotNetNuke OpenForce Post Training Conference, I came up with a tongue-in-cheek (yet still kind of serious) listing of symptoms of a flawed DNN module development process. Recognize any of these?

1. Your latest DNN module utilizes in-line CSS like it was going out of style.
2. You frequently need to release new versions due to changes that consist solely of updates to hard coded strings in your code-behind.
3. Every time you implement your modules as part of a new solution, you spend the first few days just getting them to display correctly in the new skin
4. You FTP into the production DNN site to upgrade your module.
5. You spend more than 30 seconds packaging a new version of your module
6. When you get a SQL script from source control you open up your favorite file comparison utility to see what’s changed so that you can run only those changes.
7. You’ve been curious, for the last two years, about how to use the DNN UrlControl, but you never have the source readily available, so you still don’t know.
8. The last time you upgraded your production environment you were up until 4AM trying to piece together outdated versions of your database.
9. When creating your latest DNN module, you opened up the first DNN module you ever created to grab that same piece of code that you always grab when creating a new module.