Don't wait for someone else to find your bugs
I hate bugs in my code. They keep me awake at night and keep me from moving on with my work. Some bugs confront me with my lack of focus, other puzzle me. Some prove that I don’t know everything. Some bugs are downright annoying. Bugs suck. I know you hate bugs in your code too.
There are different kinds of bugs. Sometimes there is something wrong with your logic. In specific cases, your code doesn’t work as expected. These bugs are easy to catch with unit tests. Use your imagination and think how people could use your code. You can even ask a friend to help you with it. Ever thought of ordering -1 beers?
But there are also other kinds of bugs. Sometimes your code will work just fine for a week or a month. Once in a while there would be a glitch that you dismiss as irrelevant. Only when it’s too late, you would notice that there was something wrong with your code from the beginning.
We’ve all been there. You were asked to build an application. Maybe it was a SharePoint customization or maybe an Angular single page app. You were eager to use the latest features and to try a thing or two that you haven’t used before. Along the way you came across some challenges, but hey, that’s a learning process, right? Eventually, you delivered a working solution. Working at least at first though, because then, all of a sudden, it broke.
SharePoint is a beast. It’s been around for a long time and it’s capable of many things. It’s an end-user product but also a development platform. The way you customize it, changed over the years: from .NET code running on the server to JavaScript running in the browser. But building SharePoint solutions is not trivial. SharePoint evolved over the years during which it gathered many intricacies, which you have to know, to avoid bugs. Should you dispose the Web from the SPLimitedWebPartManager? Is it okay to use declarative provisioning? Will your solution be supported, if you use the internal managed metadata REST API? What about the other 900 things that could go wrong?
This is not specific to SharePoint though. The more powerful the platform, framework or library, the more it requires you to know what you’re doing. The longer it exists, the more fixes it contains. Sometimes your choice doesn’t matter at all. And sometimes you can be punished for it as harshly as bringing the whole server down. So much for productivity. Each technology comes with its own best practices and you better know them all. It depends for a reason.
In the past you had some time to learn. Every three years there would be a new version of SharePoint. You would buy a book, read it from cover to cover and know a solid piece of it. Nowadays not so much. Every week Microsoft updates SharePoint Online and every few weeks Google releases a new version of AngularJS. By the time you found out what’s new, another release has been shipped. Just when you figured out how to use the latest features, the world has moved on and you can start all over again. Oh, and good luck finding a good book.
So you keep doing your best, trusting your gut, hoping you won’t be called in the middle of the night. When you hear about a major issue, you pray it’s not your code that caused it. You can never be sure, can you?
Knowing it all, comes at a price. It takes a lot of time to figure out each and every quirk. And things change too. And even if you did know it all, you still have to verify that everything you and your colleagues built, you built correctly. Checking your code manually doesn’t scale. Luckily you don’t have to. Have you heard of SPCAF and its database of almost 1000 things that could go wrong in SharePoint customizations? Go ahead, give it a shot and check your solutions with it. Don’t wait for someone else to find your bugs.
Photo: Jill Heyer