![\"Education\"](\"https:\/\/www.mrc-productivity.com\/blog\/wp-content\/uploads\/2010\/11\/Education.jpg\")
What percentage of IT projects fail? It\u2019s hard to say. I\u2019ve seen surveys that put the number at 25%. Others surveys push it closer to 70%. While that\u2019s quite a range, the point is this: those numbers are far too high. Even if it is \u201cjust\u201d 25%, that\u2019s still 1 out of every 4 projects. That\u2019s too many. <\/p>\n
How can we bring those numbers down? Today, let\u2019s focus on ways to reduce failure for one common project type: web application development projects. In this article, we\u2019ll take a look at mistakes that hurt web application development projects. These are chronic bad habits that turn web application development projects into disasters.<\/p>\n
What deadly sins do even the most experienced web application developers make? What common web app development mistakes crop up over and over again? We posed those questions to a few experienced developers and have compiled these answers below. Without further ado, here are 7 deadly sins of web application development: \u201cDon’t forget your audience,\u201d explains Walden Leverich, CEO of Tech Software<\/span><\/a> \u201cIt doesn’t matter what the makeup of Reddit’s audience is; it doesn’t matter what the most popular browser on Google is; the adoption of mobile technology by Facebook users is irrelevant. What matter is your customer base. Look at the analytics for your web application and make your code decisions based on that. Our user base took a good 12-18 months to decide IE6 was dead after the ‘internet’ decided it was dead.\u201d<\/p>\n<\/blockquote>\n It\u2019s an excellent point, and highlights the importance of understanding your users. What browsers do they use? What problems are they trying to solve? It\u2019s easy to get caught up in the latest technology or the latest trends–when in reality–those trends may not apply to your users.<\/p>\n These days, coding everything from start to finish is usually unnecessary. With all of the available frameworks, tools, and applications that exist today, you can probably find something that gets you most (or all) of the way to your goal. Why reinvent the wheel and build everything from scratch when you don\u2019t have to? <\/p>\n \n\u201cPurchasing and integrating solutions is much faster than developing them,\u201d Douglas Karr, CEO of DK New Media<\/span><\/a>. \u201cDevelopers can be an ornery bunch, always wanting to take on too much and badmouthing canned controls. But purchased solutions often have better support, a greater user history, and can be integrated much easier than paying a developer to build it from scratch.\u201d<\/p><\/blockquote>\n What one issue causes more problems than any other? Communication…or, a lack thereof. It destroys relationships, kills IT\/business alignment<\/span><\/a>, and ruins development projects. How does this apply to development projects? Don\u2019t start projects with undefined goals or unclear instructions. For instance, if a user asks for a scheduling application, figure out exactly what they mean by that. Their definition may vary greatly from your definition. Vague requirements almost always lead to disaster. <\/p>\n \nKen Bodnar<\/span><\/a>, CTO of SelectBidder.com, sums this up clearly and concisely: \u201cSo many times I have been asked to “Build me something wonderful” and when I did, it turned out not to be the wonderful that they envisioned.\u201d<\/p><\/blockquote>\n Some developers make the mistake of assuming their code is so well-organized, it doesn\u2019t need comments. While it may seem obvious at the time, what happens when you (or someone else) need to maintain that uncommented code a few years down the line? I guarantee you, it won\u2019t seem quite so obvious then. <\/p>\n \n\u201cGood applications will live for years, even decades, and will need ongoing maintenance,\u201d explains Leverich. \u201cDon’t curse the poor developer that has to fix something at 3AM with code that has no comments, poor variable names and cool programming shortcuts that are all “obvious.” When it’s 3AM, production is down, and your boss is looking for updates every 10 minutes nothing is \u2018obvious\u2019.\u201d<\/p><\/blockquote>\n \n\u201cThe biggest problems with applications, both on the web as well as mobile apps, is that there is not enough thought put into how the end user interacts with the application,\u201d says Hamid Shojaee, founder of Axosoft<\/span><\/a>. \u201cDevelopers often assume the user knows too much about the inner workings of their applications. This is by far the deadliest sin.\u201d<\/p><\/blockquote>\n For developers, a confusing user interface is one of the most dangerous, yet difficult problems to identify. It\u2019s dangerous because a confusing user interface will kill an application. It\u2019s difficult to identify because the developer has spent weeks working on the application. They know it inside and out. The interface isn\u2019t confusing at all to them. The hard part: Looking at the interface from the user\u2019s perspective. <\/p>\n So, how can you avoid a confusing user interface? First, as explained in this article<\/span><\/a>, involve the users from the beginning. Understand what problems they\u2019re trying to solve. Second, as explained below, don\u2019t ask the developers to handle design.<\/p>\n \nBodnar explains why it\u2019s a mistake to make developers also handle the graphics and design: \u201cThose are two different functions and skillsets. Web developers are the mechanics that deliver the artistry. Brand designers and graphic artists are the creative control and possess the knowledge base to transmit the messages of the web [app].\u201d<\/p><\/blockquote>\n In an effort to get their application shipped, or meet a deadline, proper testing is often bypassed. Don\u2019t make this mistake. The assumption that everything \u201cjust works\u201d is a recipe for disaster. <\/p>\n
\n<\/a><\/p>\nSin #1: Forgetting your audience<\/h3>\n
\n
Sin #2: Re-inventing the wheel<\/h3>\n
Sin #3: Building without clearly defined requirements <\/h3>\n
Sin #4: Assuming your code is obvious<\/h3>\n
![\"photo](\"https:\/\/www.mrc-productivity.com\/blog\/wp-content\/uploads\/2013\/09\/small_4661409838.jpg\")
Sin #5: Skimping on the user interface<\/h3>\n
Sin #6: Ignoring test cases<\/h3>\n