So, the pot got stirred last time I posted on this topic, and I’ve been promising an update to several people. Now that we got the final pieces of theplatform in place, I can get back to doing less critical stuff.
Not that I don’t think blogging is important, it’s just that I don’t care about you.
To sum up the debate, as seen from my admittedly narrow perspective, I said that out-of-the-box made no sense because most of the out-of-the-box stuff was made by marketing people to show how cool SharePoint is and not to solve business problems. The OOTB stuff is there to sell SharePoint.
Some people said I’m mad because you can to all sorts of cool stuff with OOTB. My very good friend Marc Anderson didn’t agree with me, which of course just makes him wrong, but that’s his choice. There was also a bit of talk over at EndUserSharePoint.com and probably a few other places.
Regardless, I thought I’d clarify and expand on the previous post a bit.
Why Business Solution Development Should Be Left to Professionals
For years now, database applications like Microsoft Access have been available to business users all over the globe. Being able to store business data easily seems like a great benefit, right?
However, despite the ease with which users are able to create business solutions, quite a lot of the solutions developed in Access turn out to be incredibly expensive, unstable, and insecure. Not just that, but once the business starts depending on these solutions for normal operations, the solutions turn into critical components of organization survival.
If you are a business user thinking Access and similar tools is a great benefit at this point, ask yourself; what do you really know about the second stage of database normalization. Do you even know what normalization is? Or, how is your version management and deployment testing of these applications? How do you ensure database integrity on cascading deletes?
I suspect a lot of business users will have little or no idea what any of this means, and we’re still just talking about data management. You know, that absolutely vital part of your business, the data.
Oh, and some of you will know about data development, and be very good at it, so don’t pull that “well it doesn’t apply to all” BS. To you, however, I’d like to ask how you maintain your CAS policies to prevent damage, malign or innocent, from third-party add-ons. Or something similar.
Look, we’re not spending decades learning how to develop stable and maintainable solutions just because it’s cool. There are very good reasons why these things are important, and if you don’t understand their consequences, you will get burned.
OK, I can already hear the scream of “business users know what the business needs!” and that is exactly right. Which is why I didn’t specify SharePoint in ‘Professionals’ part of the header above this section. We, as developers, know squat about your business, or any business, really. We’re developers, we dream in languages you think only belongs in a zoo (CAML, Python, Tiger). We have no idea what goes on outside the comfort of our 24 inch monitors and piles of pizza boxes. If we see sunlight, we immediately start thinking of how to ray-trace a similar effect.
That’s why we need you, as professional business users, to tell us what you need. We can make a cat bark with the proper method call, but we can’t tell if an invoice will affect the third quarter profit margins, because we have no idea what either invoice, quarter, profit, or margin means. You are experts at that and we sorely need that expertise to build the business solutions you need.
What would you think if I, as a developer, came into your company and started putting together slides presenting your business plan to investors? There are tons of ‘easy to use, just fill in the blanks’ business plan templates available online. Since the tools are so easy to use, I mean, how difficult can it be to run a business? It’s just a matter of taking those profit things and put them where it says ‘insert profit here’ and we’re good to go.
What Does This Have to Do with Out-of-the-Box?
Just one thing before I start answering this: I have never said that out-of-the-box is bad. I explicitly said that, if out-of-the-box is a good idea, it will far more often be me, as a developer, telling you, as a business user, that you should chose the out-of-the-box tools. If you read the entire original post and not just gasped and started blogging after reading the title, you’ll see that assuming that out-of-the-box is cheaper, safer, or in any way more accessible than other alternatives just doesn’t make sense.
Mark Miller was also surprised that, since I had cheered him on during SPTechCon, I was bashing out-of-the-box and no-code solutions a few months later. I am not. What I am saying is that there is a range of topics that those solutions do not take into account or even need to take into account. There is a world of scenarios that require those kinds of solutions. That doesn’t make them scalable, secure, supported, maintainable, testable, or anything that a developer would have in their bones, but that may not be what you require.
Regardless, a great number of what Marc Anderson calls the Middle and First Tier developers came screaming that out-of-the-box made perfect sense. After all, they were able to create immensely cool things without writing a single piece of code, at least not in Visual Studio.
I have also heard an argument that developing custom code takes forever and that a developer needs a week to develop something that a skilled Middle Tier developer can do in a day. Arguments like these are just completely rubbish, as a good developer will beat a bad Middle Tier developer any day, same as a good Middle Tier developer would beat any bad developer on the same day.
If you want to prove yourself, however, try to match my friend Einar’s 5 minute demo for creating a real-time request graph.
Oh, and here’s my favorite argument, developers are so expensive that an in-house business manager (who probably makes five times as much as I do) would be better. Or, one could hire a less experienced person to do the simpler task. With the tools so easily available, everyone can make valuable solutions using out-of-the-box features.
I know that. In fact, I do it all the time.
It is just one of the tools I use, however. One technique I use very often and in fact teach as often as I can is to configure as much as possible in the web UI to get a quick prototype up and running. Then, hand the prototype to business users and let them continue working on the site until they see that they solve their current needs. Once that happens, I convert that solution into maintainable and upgradable code. Users then take over the solution and do with it what they should, namely tearing it apart and creating chaos.
That’s quite alright, because as a SharePoint developer, I need to take into account that the
environment in which I deploy my solutions may be very different when I deploy it than what I saw when I started creating a solution, or even five minutes prior to deploying the code. When the business needs change, I can write new code that takes the current situation and changes it into the desired situation.
As a developer, I never touch the production server at all, or at least I shouldn’t. Also, I cannot make assumptions because users are unpredictable. If I rely on a list for a lookup column, I cannot know whether that list definition still matches what I saw when I looked at it (if I even can look at it) or if the list even exists anymore. Is the user profile service available? Who knows? The administrator may have deleted it 30 seconds before the deployment. Again, quite alright, I take that into account when I write code.
These things are requirements of creating critical applications. It’s part of ensuring that the solution is stable and adaptable enough to cope with changes that happen both in the short term and long term. It is critical for any high-availability scenario.
That may not be your site or your solution. Not all solutions mean the life or death of an organization. If you just want to share documents, there’s no better place than Shared Documents. If you want to add a list of links to an existing site, it would just be stupid to build a deployment package to do so. Who does it quicker is besides the point (I’d win, of course), it’s just that a solution package for a task like that makes no sense.
If all you know, however, is using out-of-the-box features, then you’ll always end up using out-of-the-box features. Or, as I’ve written earlier, if all you know how to use is a hammer, then every problem looks like a nail.
I have to end this now before I keep ranting for hours, but I reserve the right to make even more follow-up posts if I like.
Found this article valuable? Want to show your appreciation? Here are some options:
a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.
b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.
c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!