SharePoint sucks revisited

It’s been a while since I blogged about SharePoint, and thankfully it has been over a year since I last had the misfortune of working with it. I’ve had time to reflect and without a doubt I can say Sharepoint sucks. Here are the main reasons:

SharePoint does everything, just not very well

What exactly is SharePoint, A CMS? A DMS? An intranet? An application framework? A workflow system? A task list? A database? Or a wiki? SharePoint rather than being 1 product, is more like a collection of haphazardly slotted together mini apps. In short, everything is there, which looks great on paper, but each component lacks quality.

Misunderstood and underestimated

I’ve worked on enough SP projects now to understand the trend. At first there is a general enthusiasm towards a SP project. This is because if you’ve never worked with SP, then from a management perspective it seems like a great starting point, which will require only a few tweaks here and there to become a functional product. From a developers point of view, it at first glance appears to be just another CMS, that you can customize with relative ease. That is until you’ve actually worked with it.

Everything is convoluted

I can honestly say, I’ve never worked with a more confusing and mind numbingly over complicated (unnecessarily) product before. Believe me when I tell you (and no exaggeration here) from a developers point of view, SharePoint is a parody. If you’ve seen the series Faulty Towers, then John Cleese’s frustrations dealing with a somewhat bizarre little Spaniard are minor in comparison to the frustrations any SP developer faces when dealing with the “devil of all software”.

Another analogy comes to mind, and that is that if the sun, moon and all the planets were perfectly aligned and down to the last millisecond brought forth the perfect conditions for the antithesis of good software architecture then that product would be SharePoint.

Let’s get specific:

Lists and their definitions

Once you start getting into professional (take with pinch of salt) SP development, you’ll naturally want to bundle up all your lists, content types and fields into a WSP package. All these definitions are XML – awesome! Except not so awesome because that xml (especially for lists) needs to include most of the plumbing. If you’ve had any experience with WCF 3, then you’ll know that if was hard to configure, and by the time 4 came out, a lot of the required stuff in 3 was removed and replaced with defaults. This made WCF 4 much easier to use. Ironically none of this love was spent on SharePoint.

Now a SharePoint list is supposed to resemble a database table, in the sense that it stores tabular data. Databases however are logical. In every RDBMS that I’ve worked with, the field definitions are comprised ONLY in the table definition.

However since in SP it is possible to host multiple row types in the form of content types, in the same list. The content types and their corresponding field types are defined separately, Each with their own unique GUID. To make matters worse content types have a proprietary inheritance naming that you need to understand, or things don’t work.

Also since SP is more confused than a boy lady bug, you need to define the field and content types, both separately and then again reiterate these same definitions as part of the list (SP data table).

This means a tedious amount of work.

Web Application, Site Collection, and Site

Now this theory is covered when you first get into SP, mostly in 1 liners. At first it is confusing. The Web Application appears to be a Web Application in IIS. But then if that is the case what is the site collection? Is the site a virtual directory? But to make matters worse deployment needs to take place at different levels. And will greatly impact on if your application will actually work or not. A lot of this is hit and miss and you usually figure this out when things don’t work as you expected. This is because no one has the time to learn all this upfront prior to starting a project.

Long winded deployment process

Didn’t work? IISReset /Noforce? Did you re register the feature? Is it enabled? Did you unregister the last one? So you think powershell to the rescue, only in powershell you need to manually code in the thread sleeps to give each execution time to run because the calls are async. Still even if you’re well setup, a huge amount of time is wasted in deployment during development. Simply because this isn’t the copy to webserver, hit f5 refresh type of deployment you love, not at all.

Won’t run (or not supposed to run) on a desktop

For this reason, nearly every SP developer works in a VM, usually on some cheap laptop with the bare minimum amount of RAM. Needless to say performance is dismal. Things don’t get much better in production. SP is a resource hog of note, which is why when a framework like WordPress might run on an old 486. SP requires an entire farm to run smoothly.

This ain’t Farmville

Farms seem transparent enough on paper, however as any SP developer knows, nothing is that simple. No matter what you can expect some issue sooner or later with deployment at the application level. Typically DLL’s not quite making it to the corresponding GACs of all application servers in the farm.

 The query language is too nothing short of parody

Out of all the query languages I’ve come across CAML has to be the least intuitive. I’ve also only ever seen it used with SP. I guess it doesn’t have a huge following.

Take this SQL statement: Select * from customers where (active = true and hasPurchased = true ) or (active = false and reason = unhappyCustomer)

Seems logical even to a non developer, the same query would look something like this in CAML:

<or><and>active=true<and>hasPurchased=true<or><and>active=false<and>reason=unhappyCustomer

But to make matters worse, the ORs and ANDs are grouped into 2: So it isn’t uncommon to see statements like this:

<Where>
    <And>
        <Or>
            <Eq>
                <FieldRef Name='FirstName' />
                <Value Type='Text'>John</Value>
            </Eq>
            <Or>
                <Eq>
                    <FieldRef Name='LastName' />
                    <Value Type='Text'>John</Value>
                </Eq>
                <Eq>
                    <FieldRef Name='Profile' />
                    <Value Type='Text'>John</Value>
                </Eq>
            </Or>
        </Or>
        <And>       
            <Or>
                <Eq>
                    <FieldRef Name='FirstName' />
                    <Value Type='Text'>Doe</Value>
                </Eq>
                <Or>
                    <Eq>
                        <FieldRef Name='LastName' />
                        <Value Type='Text'>Doe</Value>
                    </Eq>
                    <Eq>
                        <FieldRef Name='Profile' />
                        <Value Type='Text'>Doe</Value>
                    </Eq>
                </Or>
            </Or>
            <Or>
                <Eq>
                    <FieldRef Name='FirstName' />
                    <Value Type='Text'>123</Value>
                </Eq>
                <Or>
                    <Eq>
                        <FieldRef Name='LastName' />
                        <Value Type='Text'>123</Value>
                    </Eq>
                    <Eq>
                        <FieldRef Name='Profile' />
                        <Value Type='Text'>123</Value>
                    </Eq>
                </Or>
            </Or>
        </And>
    </And>
</Where>

Like I said this is SharePoint, so you can expect it to suck.

Taxonomy sucks too

Ah the hidden list, and the sync issues – just Google it.

The general quirky nature of it, things I’ve forgotten about

I just remember always feeling like I was wrestling a bull while working with SP. Nothing ever just slotted into place. Everything seemed over complicated and required way too many manual steps. In short a ton of energy for a small bit of functionality.

I’ve forgotten about all the odds and ends, but at the end of the day SharePoint just sucks and there are much more cost effective and less frustrating solutions out there.

 

5 ways to be a better programmer

To me the definition of a better programmer is one who writes code that produces the desired result with less errors.

Some people might define a good programmer as one that has a vast understanding of programming languages and concepts, while this is true this definition can only take you so far – ultimately ALL programs are written to perform a function and as error free as possible.

If the average programmer had an infinite amount of time for testing and deployment then almost ALL code would be released error free, but obviously all projects were due yesterday and usually we’re developing under less than perfect conditions, and at times pushing ourselves to the max to achieve the desired outcome. Besides this the industry is generally not that concerned with deep or stress testing applications and at times your rushed out code is just expected to work.

Here are some things you can do that will improve your overall effectiveness as a programmer (these are not language specific techniques and can be applied to just about ANY programmer, including YOU)

1. Get a second opinion: In the old days it was taught that a developer should read a considerable amount, and search the internet as much as possible prior to asking colleagues. I’ve even read surveys from those times where developers actually felt embarrassed to ask questions to fellow developers in the fear that they might come off looking inexperienced. I would say shed that fear, and the good news is you also don’t need to pester those you work with, enter the era of www.stackoverflow.com, if you don’t have an account create one immediately, its almost mandatory for a modern age developer to be using and contributing to Stackoverflow.  Stackoverflow WILL make you a better developer, and by using it, You directly contribute to the collective knowledge of all things programming related.
2. Don’t trust your own code: Be highly suspicious of your own code. Every error in your application is almost always a direct result of your own code. View all code with suspicion, never think about any function as simple. Don’t think to yourself – “I’ll write a quick function to send an email” or “I’ll just quickly append this line of text to the end of that file” or “I’ll very quickly insert into this or that table”. You have to start thinking. Stop coding for a minute, and think things through. Every time you write a function, think “What could go wrong”, then convert this to – “What WILL go wrong”. That little append method you wrote might expect a file to actually exist, or that file could be locked. That database might be offline, that email server might be undergoing maintenance. Assume nothing, except that every function you write is inducing more possibilities for error, and its your job not only to write the function, but to eliminate as much of this error drag that WILL be caused, to the best of your ability each and every time. Start thinking of functions as in code / error drag ratios. Don’t write a function unless you are certain you can almost eliminate ANY error drag induced. It should really surprise you, after you’ve done this and your application ends up with a logical error in production.
3. Think and relax: This might not always be possible, but where ever possible exercise your right to be relaxed on the job. I’m not suggesting you take hours off to play network games. What I am saying is, each time you are about to write a function or a piece of code, enter into the development of this function with a clear mind. If you need time to think things over, do exactly that. Don’t cave in to pressure from management to “look busy programming”. It’s acceptable to be sitting at your desk just thinking things though, if it helps you visualize, get some writing equipment, not on the PC and make notes, and draw diagrams, or open up notepad and run through some real use cases. If you take 50 minutes in the hour to think things through, and 10 minutes to implement your idea, even though it might not be finished, its still overall WAY more effective than thinking for 2-3 minutes, and then implementing something in 20 minutes, job done – go home, and then get a support call the next day -1 repution for You, Your Company, Your Product. When you code, you should be coding at the speed of a dinosaur, but your mind should be thinking at the speed of light. The text you are typing is coming out slow, but its quality, because you’re focused on the bigger picture, what your code is going, how it will affect the users, how that one line will prevent support calls, how that function you’ve added will mean your code deploys without you having to be there, the list continues. As a developer you should have a lot of considerations in your mind when you code.
4. Modernize: If you started coding 10 years ago, then its likely your language/s of choice have seen a vast number of improvements or language enhancements. Stuff you used to write a function for years ago, is now an inbuilt language feature. Before you might have needed 10 lines of code to accomplish something that now only takes 1 line of code. Its your right as a developer to receive skill enhancement benefits while on the job, but so few companies actually offer any tangible skill improvement programs. If you were a Soccer player, most of your time on the job would involve training. As a developer you’re expected to know your job upfront, with very little emphasis on upgrading your existing skills. I’ll cut it short, You are the only one who can make your skill improvement happen, and you need to do this gradually and build it into your every day life. Don’t just write a function doing it the old way, take the time out (yes even if that means at times digressing for an hour or 2) to up skill. Use Stackoverflow or Google and find what is best current practice for the way you do things. Tell your employer that you are actively developing your skills, or that you are researching an improved way to implement if they are curious. Don’t push management to provide you with training, in my experience nothing good has ever come of it.
5. Always push for more testing: This might not directly improve your coding skills, but it does go a long way in terms of PR. If functionality you’ve been working on hasn’t undergone ANY testing, then you need to explicitly emphasize this. Don’t release something and say that its ready, complete or done, if it hasn’t been tested. When I say tested, I mean thrashed by someone other than you, who can try and extract as much errors or usability issues as possible. I’ve written this article to be as practical as possible, because of this, I will assume you don’t have a team of 5 testers just waiting to take over your code for testing, and you don’t have ANY real testing in place in your organization. You need to mention this EVERY SINGLE TIME you release something, because its something non technical members of your team very quickly forget. Hand over functionality always under the clause that it needs to be tested. If no testing is possible, then you’ve covered your base when errors do come back (and they will). The point is always make the point known that you are indeed a man short (the tester), this goes a long way in protecting your reputation as a developer, because the sad reality is not enough testing ever takes place, and if you don’t make others aware of this, you’ll end up just looking like a 2nd grade developer when issues happen.

And finally – above all else take errors very seriously and fix them ASAP, its ok to have some error drag (bugs) in your application. No one I’ve ever met has ever got to the point where they can release a perfect program that’s 100% error free, but what is more important is how quickly and effectively you deal with these errors when they occur, this includes your turn around time, and your initial ability to trap, log and notify these errors.

Preview your web pages in IE (6,7,8)

The market has long been screaming for a way to test multiple versions of Internet Explorer on the same installation of windows.

Along comes Microsoft Expression Blend 3 Super Preview (free download),  which claims to be able to test your pages in IE 6, 7 and 8 all on the same machine, and without installing previous versions, the paid version can even do Firefox.

Now I know a lot of the web development community are excited by this product, but I personally am not too sure this app will find its way into my list of useful web development tools.

This product is free for a reason. I can’t see this as a viable option really for a serious HTML handcoder / Javascripter.

So what exactly is wrong with it. It starts off looking really good, the installer is clean, and the app has a decent enough interface.

1. Its too slow. It takes so long to load pages into the preview it goes against the flow of the way I design. This is to make small changes, save and check in each browser. This way when an issue comes up I can correct it without having to rewrite too much code. Unfortunately during testing, I found that a refresh could take up to 40 seconds per page on my live site. I am constantly saving and checking and so this product would just drive me crazy with all the wait time.
2. I guess the main reason I dislike it: Its called super preview, but it doesn’t give you a live preview option, where you can click around and test the functionality of your site. It only loads a static view and after that the JS or dynamic content cannot be checked, unfortunately.

So if you really want to know how to test in IE 6, 7 or 8. Here are some options for you.

http://stackoverflow.com/questions/574463/running-ie6-ie7-and-ie8-on-the-same-machine

Is adapting early taboo?

I’m a developer who uses Microsoft technology, I have been for over 10 years, and have been a Windows user since 3.1 and before that MS DOS. Before I used DOS, I owned a ZX-Spectrum that was a small home computer with a whole 48k of memory.

When I reflect over these computing years, I have to say something has changed in the way we perceive new products, particularly if they’re Microsoft products. In the early days, any computing progress was welcomed and at times only a select few got access to new and emerging Betas. Things certainly have changed.

Microsoft lately release beta versions into the wild, and people like me adapt and start using them. I had Vista when it was called Longhorn and barely even worked. I used asp.net when it was still called asp+, I had the offical RTM Windows 7 2 months before it launched in New York. I now have Google Wave, and I’m experimenting with Visual Studio 2010.

Companies release beta versions to the public because of 2 main reasons.

1. Companies like Microsoft realized that beta versions of their product were getting leaked, because the technically minded wanted more insight into up and coming products. Technically minded people are great at surveying a product, and identifying missing features or finding bugs.
2. The deadline for any product is always yesterday, and its nearly impossible to catch and trap all bugs. Its also expensive to pay testers

Testers are a rare breed in all my development experience I have never worked on any product that has been tested to death. If anything most products only undergo about 3-5% of the testing that they should go through. This is why people like Jeff Atwood say – All software sucks. So if we don’t test our products who will? Well usually the client ends up taking on some of this testing, no one admits this though, and the customer ends up just being a frustrated user who reports the odd bug. But why not get software specialists to test products? Along comes Betas – essentially what Microsoft are saying is – HERE GUYS PLEASE TEST OUR PRODUCT!

Not that this is a bad thing – because for this testing service you do get early access to a product that you might otherwise have to wait an extended period of time for. I don’t mind any of this, of course you can always look at it dogmatically and think – “Why should I be testing for them?” The answer is you shouldn’t be, but if you don’t, you can be sure there are 1000’s of other developers out there willing to dedicate their time, so you can be sure this release model is here to stay, and its already become the standard of how software is released.

From a Microsoft point of view – I don’t think they fired their testers in exchange for free beta adapters. I don’t think they had great testing capacity in the first place – hence events like a blue screen of death at the Win98 launch or the utterly useless demonstration of speech recognition that shipped with Vista. So this new model can only benefit the end user.

What I do have a problem with is the negative attitude I face in the industry when wanting to adapt early. The .net framework is the best example I can think of. Version 4 is on the horizon but it seems most companies are still afraid of anything above v2. In my experience I’ve had to really struggle to get guys using v3.1 or v3.5 and because of this, in the time I’ve been using v2 I’ve lost out on all that new experience, and sad to say my LINQ is nearly non existent. Now v4 is coming out, and so all I say is “here we go again”.

Learn as much v4 cool stuff as you want, grab that VS2010 Beta and peek at the cool new language features in C#, but is it really helpful? you can be sure us early adapters will just get frowned at for another 2 years before prudent IT departments stop being afraid of it and brand it as safe to use.

So this is the frustration in being an early adapter, you get into new tech early, and end up having no real use for it until its been screened by the most anal retentive and gets globally accepted. Rinse repeat.

A programmers attempt at designing

We all know programmers are not designers, but sometimes a programmer is forced to push out a design. The fact is a web application developer often has to work closely with web designers, and their influence is bound to rub off.

You rub my back I’ll rub yours

Most programmers have friends who design, and it should be possible for designers and programmers to share their skills in an on going way so that programmers never have to think about design, in exchange they offer their programming services to designers. However in theory this simply doesn’t work out.

The fact is most designers simply do not require the full blown efforts of a developer most of the time. Most designers require some server functionality here and there, but typically this functionality can be found somewhere in an easy to implement script found using Google. Yes we’re talking about stuff like contact us forms, etc.

Another thing to consider is that most highly experienced designers are short on time. Every single designer I know, is always busy with some or other freelance project, and typically they get paid for this. Senior designers also have nothing to prove, they don’t need to beg your attentiion and so are not highly motivated unless there are some real incentives on the table. It’s a bit of a catch 22, because a less experienced designer might be willing to assist, but the end result can also end up being questionable.

Design as a framework is less reusable too, in comparison to programming. Sure some elements of the design can be reused, but designs should be distinguishable, and the web is also fashionable, what looked good last year, looks old school by today’s standards. I would say, because of this, each design is a custom piece of work, so the designer is less likely to get any inadvertent kick backs from this, than a programmer for example, writing an open source fully reusable library.

Because of these issues, I have been encouraged lately to help myself, and I decided to knock up a design for a small charting business based in Knysna, South Africa. I managed to complete this design and implementation in 5 hours, while the site is not 100% complete, it at least does give an example of what a programmer is capable of, when he/she commits to the situation at hand.

Now I was not completely in the dark, and I had input from an experienced designer, but I am proud to say most of what you see there is my work. The idea here is not to point you in the direction of a perfect design, but simply something that’s functional as some inspiration to you, if you are a programmer, before you say – I don’t design or I can’t design, have a look : http://www.jjsfishingcharters.com/default.htm

How to get SharePoint 2007 to run under Windows 7?

Ever wanted to know How to get SharePoint 2007 to run under Windows 7?, Well you’ve come to the right place.

This solution should work with both 32Bit and 64Bit versions, but you’ll be pleased to know its fully tested to work with Windows 7 64bit RTM.

Ok let’s get started.

You’ll need:

• Your Original SharePoint 2007 with SP1 Install media. If you’ve got an MSDN subscription download the ISO and mount it.
• SharePoint 2007 SP2 (either 32bit or 64Bit), can be found here (from Microsoft)
• A setup helper application , located here
• A database (I would go with SQL Server 2008, or get an express 64bit edition)
• IIS Running

Overview:

To get SharePoint running on Windows 7 is not that difficult. We need to slipstream the original installation media with SP2 (because Win 7 won’t install prior versions). Then we’ll fire up the setup helper app, browse to the slipstreamed setup, select the setup.exe and it will now bypass the OS check. Once this is done we can install MOSS. After MOSS is installed, we will install a database. After this, we will run the SharePoint Products and Technologies Configuration Wizard, provide the database instance, and MOSS should install nicely.

Step 1 : Mount your install media, or insert the DVD (remember this is MOSS with SP1) or for example (en_office_sharepoint_server_2007_standard_and_enterprise_edition_with_service_pack_1_x86_x64_dvd_x14-40187.iso)

Step 2: Copy the setup folder on the disk either the 32bit or 64bit folder to a local drive on your PC (for example: c:\MOSS2007)

Step 3: Download SharePoint 2007 SP2 can be found here (from Microsoft)

Step 4: Extract SP2 – and place extracted files in the updates folder of the copied original install media (for example c:\moss2007\updates)

This can be done… by doing this… (here is a 64bit example)

officeserver2007sp2-kb953334-x64-fullfile-en-us.exe /extract:c:\moss007\updates

or

officeserver2007sp2-kb953334-x64-fullfile-en-us.exe /extract

If you don’t provide a path, you’ll get prompted to browse for one.

Step 5: Turn windows features on, make sure you have all of the following enabled:

Step 6: Install SQL Server 2008 You decide on a version.

Step 7: Now the fun part… install MOSS using the setup helper application and it should go through without any problems at all….

Good luck – and have fun…..

And if you need more help just ask 🙂

Mono failed miserably

I would just like to caution you guys on using Mono. A lot of hype is out there claiming that Mono is a “mature solution” and you get the impression that its an easy port. I am sure a lot of basic code will port without a problem. Its unlikely you’re going to face any problems with a simple “contact us” form.Just be careful if your app is complex, because like I’ve just discovered, its a lot of work getting things up and running in Mono.

At this stage I am not sure if my app will ever run the way I wanted it to under mono. I will have to debug it line by line and rewrite to accomodate Mono specific code.

None of this is what I had in mind, I really thought it would just work out of the box. Well it doesn’t.

I guess I might undertake it as a personal challenge to get it all working, but I can’t say I will enjoy working with Mono, its not very well polished.

Lastly don’t under estimate the Linux configuration you’re going to have to undertake to get things running. If you’re completely clueless with Linux, expect to get very frustrated, Linux can be a bit daunting, I dare say even a bit annoying, if you’re not used to it.

A pitfall of using XML for data storage.

XML is one of the those useful technologies that was designed well, and has a solid foundation for the future. XML encompassing XML, XSD, XSL, XPath etc. XML is a relatively easy technology for a web application developer to get into because most web developers already know CSS and HTML principles, so XSL makes sense. Most web developers also know javascript and DOM, so XPath comes naturally. I must say I am a huge fan of XML and its many implementations.

Every .net developer should know a little bit about XML, because .net applications are configured using XML. .Net has a lot of built in support for working with XML, and serialization is extremely easy and efficient. If you’re a .net developer lately, you’ll find a use for some more advanced XML usage sooner or later.

With all this XML staring at you in the face, one day you’re going to wonder if you even need a database, or will XML file storage suffice, here are some things to watch out for.

1. XML Storage and Retrieval is great for small operations and small file sizes, so its a great alternative to a database for simple solutions, just ensure at the start of your project, that there won’t be a phase 2 or 3, where suddenly the project grows out of proportion and then WHAM! You’re going to have to sit and figure out how to fix the mess of having large XML files. You might be safer just starting your projects using an express database, if you’re trying to cut down on licensing costs, and you can always scale it later to a full DB product, without rewriting huge sections of your code!
2. You might think “I will cleverly break my file size down, so that I don’t have this problem”. Yes you can, and you will eventually have to, put in a lot of manual work to get the storage professional enough for Enterprise production usage. If you had gone the DB route, you would not even be thinking at this level.
3. You’re going to have to write objects to insert/update/delete/select from your XML files. Including Serialization and De serializing from file. – SQL you’re going to write SP’s or SQL queries, and you’re going to need a DAL (Data Access Layer) But you can save yourself a lot of time if you use nHibernate for .net, its free and it works.
4. You can’t store an unlimited amount of xml files in a directory. Sure technically you can, but you’re in for a few bad surprises.
   1. How will administrators be able to manually browse a directory containing 500k files?
   2. Your C# code surely has to itterate through the whole collection of xml files, are you really intending on having a foreach file in files loop? I wonder just how stable your app is going to be.
5. Files Lock, yes they do, and working with XML means overcoming all that locking yourself. SQL is much better at handling transaction based access to data. You get all the benefits of decades of research that has gone into our modern RDBMS systems. If you’re going back to a file model, you better hope your app does not scale.
6. Files Corrupt : The question is “When?” and the answer is “During Serialization when the server (a) suffers from a fatal error (b) total power loss. You might think the odds of this happening are slim, but in my personal experience it happens more often than you might think. You see if you’re using a database, you might essentially loose 1 insert statement but the rest of your database will remain intact, its also highly unlikely you’ll get 1/2 an insert statement, mostly it will fail at once. With XML and your .net serialization techniques, you’re saving an XML file all at once. This means that should anything go wrong, you’re going to corrupt that XML file (Yes the whole schema!) and that my friend is critical data loss. Prepare to (a) Either invest large amounts of time making your app robust enough to recover from corrupted xml schemas and expect some data loss (b) Deal with the full brunt of the problem when things go wrong, and critical data is lost.

You might think “Microsoft use XML, so why can’t I?”. You can, and I suggest you do, just use it for the right reasons, use it to store information that will not scale, like configuration files. Use it for data exchange, possibly logging, if you don’t mind the extra size. Just be very careful you don’t use it as data storage to cut out a database, and end up inducing huge extra costs, when you need to revert back to a conventional database, or write costly workarounds to the pitfalls of XML as a data storage.

A lesson in error handling by Microsoft

Don’t you get tired of hearing what we can’t or won’t use?

As a web developer with over 10 years of experience the most perplexing things I come across is how certain companies, development teams, managers or partners undermine certain technologies. You come across this all the time, good technologies or products not being used because someone in the team is prejudice. The justifications for ignoring, sometimes the technically superior solution can be amusing.  Here are a few of my pet annoyances that I’ve encountered most often.

1. Flash is a dirty word for some – I often get told “We can’t use Flash in the solution “. Its usually not up for discussion especially on larger projects or intranet related projects.  I am not a flash developer, so I don’t push it for personal reasons. but Flash when used correctly can add value to the end user. I am not talking about changing the app to being “a Flash Site”. Using it for certain tasks like multiple file uploading or media viewing is not technically a bad idea, and its cross browser compatible, unlike an Active-X control.The 2 main reasons Managers seem to come up with for not using Flash are: (1) It violates some security policy at the client (2) The client should not have to be bothered to install the flash component to use the application. Both these arguments really hold little weight at all. If you’ve coded that Flash object correctly it will present no more of a security risk than any other component in the system. These managers also seem to think that Flash is somehow banned by IT policies in large corporates. It simply is not! The reality is that most business users are allowed to have flash installed, and most corporates will intentionally block access to certain sites like YouTube or MetaCafe, rather than blocking the underlining video hosting containers to these sites. Yet still time and time again, I see inferior components being used in the solution (media player for example) simply because of unjustified paranoia.
2. We don’t want a Java Applet or Active-X. While I agree Active-X is getting old and stale, and I don’t have any love for Java Applets. Both these technologies have their purpose and place. The point is not to rule them out entirely because of management phobia or some techies opinion based on half hearted arguments or hear say.
3. Silverlight. Again I am not a huge personal fan of Silverlight because I believe what ever Silverlight can do Flash can do better. But I’ve heard really stupid reasoning for not using it. The main reason is “The client won’t install this component” or “Its an additional download”. Sure its an additional download, but its less than 5MB. I think its about time we started giving the user some credit, we do after all have quick ADSL connections in most offices.
4. Limiting the version of the .Net Framework. This is a common mispractice I’ve come across a lot of the time. Managers insisting that they simply cannot roll out a 3.5 Framework based solution because the client is already used to V2 Framework solutions. Common arguments include the following: “We’re not sure on the impact of hosting v2 and 3.5 simultaneously”, “We simply cannot include 3.5 features because the application is written in V2” mostly these arguments hold no weight, they’re based on speculation, and no due diligence has been done.
5. Open Source. I’ve met a certain stubborness along the way too regarding Open Source components. Some companies are totally against using Open Source components in the overall solution. The reason is typically because of the licensing attached to these components, and the maintenance issues that could arise from using these components. Hence great value adds like Log4Net and nHibernate are not even considered by many, and instead expensive custom solutions are implemented.
6. Non Microsoft Alternatives: Some companies are so focused on using strickly MS Tecnologies that they seem to ignore any other solutions that are out there. The message is pretty clear really, there are lots of tools and components that will do the job better, perhaps its about time to really survey the market before diving in and doing it by the Microsoft book.
7. “Expensive 3rd party components” : I’ve been in situations where I do not really want to develop a certain component due to time constraints, so I have a look at buying certain black box components, mostly to do with the UI of an application. Now its true a lot of these components are not cheap at first glance, but if you really do the maths and consider the time it takes to build that component then things look a little more viable. Mostly I find that eventually the budget for these purchases do not get approved, and instead the functionality gets scrapped from the solution. Cutting corners at the end user experience.
8. Skype or Messengers: Its a good idea that companies have strong security policies in place to avoid corporate wide infections, or any intrusion. What I am against is the inconsistency often displayed by the Networking Department. Don’t ban instant messaging but allow cracked software including keygens. This type of inconsistency is commonplace. Skype and Messenger can actually boost your productivity. I remember before Google Days a lot of technology experts would pen together as MSN groups to help each other. It often was quicker to ask another developer than to research the topic.
9. HTML 4 Transitional : Purists will argue that everything should be done using XHTML Strict. I agree its a good idea to have well structured code, but this can be achieved using either HTML 4 or XHTML. Its even possible to code both at the same time. If you’re more comfortable coding your application using HTML 4, then that is what you should be using. Remember at the end of the day that the end user doesn’t care at all what the site is written in, as long as it works, and well.

I suggest we all take another look at our motivations for not using certain techs and get down to the business at hand, making usable, functional and good quality business applications.