Bad Programming Practices Know No Boundaries

Thanks to Alan Stevens for retweeting this blog post by Steve Smith. I’ve met Steve at a number of conferences and he’s a really sharp programmer. If you read his post and come away thinking his anti-patterns and anti-practices don’t apply to SharePoint then you need a hefty dose of the red pill – and you need to visit http://www.codeplex.com/spg right away.

I feel compelled to point out the practice of Premature Optimization, as Steve calls it, is actually a best practice with regards to SharePoint programming and not an anti-practice. If you model your code correctly (according to accepted patterns) then you should be interacting with SharePoint at only one layer – the data layer (regardless of where this lives in your model). Always, always, always optimize this code, no matter what your other layers may be doing. I guarantee you that the efforts spent optimizing such code will pay dividends on future projects (you do write reusable code, don’t you?). As I pointed out in this post, Steve’s approach exposes a fundamental problem with TDD-type methodologies: just because code passes a unit test doesn’t make it good code. Unit tests do not, and should not, validate performance. It’s up to you as the developer to insure that the code you’re writing doesn’t just pass the test but also that it meets the feature requirements of the customer. Show me a customer that isn’t interested in application performance – especially in SharePoint – and I’ll make you a great deal on some ski resort property in Fort Worth. When it comes to SharePoint, optimize early and often if you want code that’s modular and reusable.

I’ll also add that Steve’s Reinvent the Wheel (RTW) section has particular merit in SharePoint-land. There is so much that SharePoint can do out of the box; are you really sure you need to write a web part to solve the user’s problem? Why not spend a few minutes searching the web or trying out the UI before you open Visual Studio? Also, take into account what it’s going to cost, in productivity terms and bottom-line dollars, to maintain that shiny new widget you’re about to write. It may just be more cost-effective to show the user how to create an InfoPath form that to code up yet another ASPX page. Just remember, when you have a hammer everything looks like a nail – try putting down the hammer and digging around a bit in the rest of your toolbox. You might be surprised at what you find.