<< Back Home
Web Development : 10 Secrets to Building Superior Web Solutions that WORK!!!
or "10 Things MOST Developers do NOT do when they build websites and applications!", 03/18/05
PART I - Most Software is Not Designed for Changing Business Needs
Your website may LOOK GOOD! Your internet-based business portal may SHINE and SHIMMER with "coolness", and "sexiness", "intuitive usability" and "global appeal". Business-to-business experts may applaud your web service as functional and quite powerful. In your e-commerce portal, users may flock for your products, and your shoppping carts may always be filled. Your document managment system may allow you to collaborate with confidence, and your Content Management System may be billed as the "Best of Breed" in the industry. You may have the fastest server, the most expansive database, and the best (and cheapest) most productive "outsourced" web team that money can buy. You may be towards the end of a large web development CRM or ERM project that just bristles with hope and joy and excitement from all company members involved.
But wait.........
Thats right, wait....
And ask yourself one simple little question:
HOW EASY OR HOW HARD IS IT TO CHANGE ANYTHING IN YOUR WEB APPLICATION?....its that simple.
Can the product or code be changed with ease? I mean, if I want to change the color of a button, put in a new logo at the top, make the site frozen versus flexible in layout, or add a new field to the database, or add a data relationship the developers failed to include, is that possible??? ANd if so, how easy is that to do? Sounds like a simple question, right?
You may say, so what? What does that matter? I can change what I need in the website page, or in the database, or in the web administration piece that comes with my web application. Or I can simply call my developer....who works for free, right?.... and he/she will be around the next ten years as my needs change and the application needs recoding, right? Wrong! How many developers you know works for free. How many will be around years from now to help you with your web application of choice???
So, I ask my original question again, because its so important to the point of this article.....how easy or how hard is it to change ONE ITTY BITTY TINY SMALL LITTLE PART of your web application? I am talking about that one little thing the application just wont do, and you need. I mean, what does it take to make that small tiny little itty bitty change, NOW? Can you call your fellow developer to do it, and is it easy for him/her to recompile or recode and post to the server? Or if you are a developer and YOU wrote this masterpiece of digital coding, can you quickly open a page, re-type something, FTP it up, and its done? Or is it much more complex, the steps you need to take. Maybe you are lucky and you find a small trick in some code on your server, and changing that, in 5 seconds, its done! Ok, then I say, what about the next change....and the next one....and the next one? Surely as time goes on, and you USE your new expensive web application, you will want to make it do new stuff? Will you have to buy another version, take time to integrate another version, or worse, customize it yourself with no training on how it was architected. Most likely its architecture is NOT SIMPLE, but VERY COMPLEX....and that means hours if not days trying to figure out its technology just to make a small change....yuck!!!!
I am NOT talking about the data you add and upload and edit in the site, folks. I am NOT talking about all the widgets and cool stuff that came with your web application product out of the box. I am NOT talking about all the interesting ways you can configure the system using its pretty little web interface, via a login page. I am simply talking about the day you arrive at work or log into your application or get a call from the CEO or your boss and he/she says, "hey, we need to change this to do this instead". Sounds simple, huh? Its simple until you start the painful investigation of actually HOW THAT WEB APPLICATION WAS BUILT in order to make this new unconventional change thats required!.....and thats when the trouble starts...
Now, lets step back and assume you have a HUGE major web application and business process and web service application running across many servers, with clustering and redundancy, and distributed databases, and web services exporting xml night and day, and you need to have one tiny change made thats reflected in all parts of the application. How much time in minutes, in hours, in weeks, in months could such a change take. Time is money.....you have not forgotten that, have you (if you are in the business world, that is!).....and I mean, to migrate that change across your network(s)?
Now lets ask what happens if instead of one small tiny change, you have THOUSANDS of small issues, changes, additions, modification, web parts, modules, data, and errororing issues that need to be addressed in your website. This is what generally occurs over a period of several years using most software applications.....and so many changes generally means you either pay top dollar for a technology services professional to come figure it out, or you hire someone to work for you, or you ditch the entire project. It's getting very expensive, isnt it. Maybe you get lucky and the web app has all the bells and whistles to allow a non-programmer to change whats needed. And it becomes a great tool for you. But we all know businesses change, as does business needs. At some point you will see what was once a few changes creep in to thousands of tiny ones, and thats when the pain comes......
That's right, here comes the real pain years after you bought your shiny brand new web application, not knowing you would EVER need to modify it. So, multiple my question a thousand fold, and tell me how much time....how much of your precious time, that is....is required to addresses changes to your expensive web applications? That seems to be the killer question FEW WEB DEVELOPERS ever care about, few managers think about, few engineers really consider when they implement projects and code and data. Most people as well as most developers, if you look at the growing complexity of web products and the volumes of code that go into them, really are not thinking about any possible CHANGES or MODIFICATIONS or DATA ISSUES or BUGS in their applications as their use expands beyond its boundaries, which it is certain to do. What really happens over the LIFE OF AN APPLICATION?!? The only question MOST DEVELOPERS ask is....DOES IT WORK NOW AND SOLVE THE PROBLEM PRESENTED. Does it SOLVE THE CLIENTS PROBLEM? Sorry, but thats very bad! The answer at some point during development is YES, of course. So, they call it done, and out the door it goes!!!!.....and that is the beginning of the end for your web application......its "alpha and omega", as my Grandfather used to say!
HOW EASY OR HOW HARD IS IT TO CHANGE THE CODE? If you cannot answer that in clean simple language to yourself, your content managers, your supporting development team, to your CIO or CFO or Controller, then problems are about to occur, and it is truly the beginning of the end. To think that any piece of software can have that level of flexibility is almost insane to most developers way of thinking, yet on another level, actually quite possible, I believe. The ability for developers to do a really good job at that aspect of their web applications as they develop them is missing entirely from todays landscape of developers, and especially .NET developers. Why? Because most developers dont care about the way in which
CHANGE affects web applications. And by designing code and organizations or lack of planning, most developers and managers are creating CRAP, and programs that are DOOMED TO FAILURE....at some point in time. By NOT thinking about the bigger picture and thinking about how to assist customers when they feel the need to modify or change their code for their personal purpose, most software is doomed to fail. As good and bad as many feel Windows is, its number one world wide for business and personal use simply because it WORKS, WORKS WELL, allows some customizations, allows all levels of personalization, is well documented for all types of users and developers, and user friendly in how it interfaces with all forms of users. Despite security issues and flaws, you HAVE TO LOOK AT SUCCESSFUL PRODUCTS AND SEE THAT THOSE ARE THE FUNDAMENTAL REASONS WHY THEY SUCCEED! And so when I ask the question about ease of use in making a single minor change, Im trying to cut to the very bone of how programs, and especially web application type products, are used! People, at some point,no matter how rigid, or how flexible they are as people in following "instructions" in using a given application, will need to change, modify, expand, and alter website development, and its one failure in designing web applications that address that issue that is at the top of my list for Top 10 Secrets of Web SOlution Success. So before you read my list, just think about your web applications, and how they help you, and how wonderful they are, how pretty, and how powerful, and how usable....but.....think about flexibility, because it is inevitable that ALL WEB APPLICATIONS WILL CHANGE, and when that day comes and those changes escalate,
the great web applications that have been build on organized code and forthought in terms of customization and intuitive usability will be the only websites solid enough to survive the next ten years of use. And if you REALLY really think about that statement, and then you go in and really look at your web application, your CRM website, you enterprise web service, your business process systems online, your web portal, and your content management and b2b systems online, you probably will see an application that works well within its small sphere of influence, but its proprietary nature will be its demise....some day.....in serving your needs. ANd that really sucks! And so I say, that the inability for developers and engineers to design software thats flexible, open-source in terms of code, and simple in design means as business needs change it will get more and more expensive for a company to support and manage their web application projects. This is a huge failure in today's development community....especially in the lazy .NET community.
PART II - Disorganization on Every Level
Let me just cut to the chase on this issue. I don't care how COOL your .NET or JAVA or PHP or ASP web project is in terms of supporting enterprise level business proccesses services and content management. If its designers did not take the time to carefully organize and plan for all levels of that project, at some point the shear volume of time it takes other developers and customers to LEARN ITS DISORGANIZED AND COMPLEX STRUCTURE (ie. Microsoft Sharepoint, .NET Rainbow Portal, among others) and modify or customize the product will begin to outweigh the initial cost-savings from its initial purchase, use, and implementation in your organization. Don't believe me on how this affects things, then I challenge you to add up all the hours required for most developers to SUPPORT web applications over its complete lifetime compared to it time to develop. YEs, thats a fact! It usually will take many more hours to customize small parts of a web application by those outside the initial development group that it took to design the thing! I call this very EXPENSIVE and TIME-INTENSIVE problem in modern software the
ROMAN EMPIRE PRINCIPLE. Maybe you have'nt heard this but some archaeologists insist that the main reason the Roman Empire fell in Europe was because of INFORMATION....thats right, it was the inability for the Romans to manage the huge and very compelx information and communication gaps that they had that caused their eventual downfall. The actual term is a "failure in complex societies". This means, that as information and communication needs grew, their system of communication failed to deliver what was needed. This can be seen in the failure of parts of the Roman empire to allocate troops effectively in various parts of Europe in combatting the barbarians and others that overran their empire. It also was expressed in food rationing, and communication of new policies that in more distant areas of the empure were not received for months if not years.
The point I am making is that disorganization is like a virus....as it spreads into a project that has failed to build upon good solid project management and leadership, such chaos creeps into all levels of a project. Where internal company projects occcur with no management of tasks, as is frequently seen in smaller IT companies, those "patches" or software or code fixes eventually cost money to support later when OTHER DEVELOPERS come into try and figure what was patched to or chnaged to fix the web project. Remove management and let upper level people dictate changes without managerial and organizational control and it will eventually cost that company interms of the increased time it takes to learn what past developers have done. This lack of project management also creeps into other spects of software development, and speed and delivery begins to outweigh effective quality control, and the final product may LOOK AND PERFORM WELL, but as implemented by clients and used and changes are made, such disporganization creeps in and eventually eats away at the success of the project. Most developers ONLY CARE ABOUT PROJECT UTILITY...ie. "does my code work!" That has NOTHING to do with following a coding scheme or data scxheme thats rigidly followed across all departments when designing software. All the big players in software do this...its the smaller IT companies who failt to see this and thus, never grow! Why? Their products never reach the organized level and thus quality level to eclipse other competitor products and thus, they remain among the bottom feeders. Its a strict policy of making QUALITY PROGRAMMING AND ORGANANIZED PROJECT LEADERSHIP even at the expense of more time and money within the department, that keeps a small IT company small and a high quality large growing IT company growing. Companies, over time, will remember you for your quality of product....nothing else....
Let me give you a very simple yet underrated example of something nearly ALL DEVELOPERS take for granted when they develope web applications. Most developers dont know how to keep their physical file, dll, and folder structures simple on the server. The ability to manage a poorly designed web application whose file and folder and naming structure is based on a set of arbitrary developer-based designs, means interpretation by hundreds if not thousands by outside developers and engineers world wide who try to modify or change that structure for their companies needs. If I built simple website with file names using random numbers and I had a thousand businesses all trying to dig in folders of my project to find the right file to open and change code in, how many complaints would be propogated online concerning how bad the simple file naming scheme is? How many thousands of lost minutes if not hours or days would occurr for those thousand companies trying to find that file? Do you see my point?
Something as simple as file and folder organization, done poorly, expands among a thousand companies into thousands of manhours of support for everyone! Confusing documentation or code or class systems inside .NET code (ie Storefront E-commerce software) means thousands of hours wasted trying to figure out how and where to add a simple piece of code into that web application in order to say add a simple form field. MAybe the software is so robust (ie Peoplesoft, or SAP) that you never see those problems. But when it crashes, or errors out, or the day you find you DO need to add that small piece of data the system wont permit, how bad will it get trying to figure out how a website is designed. I am talking about files, folders, naming taxonomy, code, classes, objects, markup and CSS, xml and server configurations, etc.
Why do Developers design such bad code and file and server structure?
Web Developers and Managers are lazy! and its all about money and time-to-delivery! Its NOT about quality or designing for the future? Those companies that go to India or Russia or China and get an open-source, cheap or free Contenet Managemnet Software system built just for their company may save money and get it done fast. But years from now, HOW MANY SHEAR HOURS OF TIME AND WEEKS AND MONTHS WILL IT TAKE AMERICAN WEB DEVELOPERS TO REVIEW, RECODE, FIX, MODIFY, or REMOVE parts of these entrprise level applications to make them grow as the business's needs grow? If the product was rushed and hastily built with various levels of disorganization and with little thought to how any single company may want to change or support that product, the amount of time to rebuild or modify such software many exceed the cost of its original purchase.....all because of poor planning, engineering, and disorganization. This results in one scrapping the software and buying another. HOW MUCH MONEY WAS SAVED IN THAT SCENARIO???
It does not take much, guys to do a GOOD JOB OF ORGANIZATION and planning. Don't get lazy. Stop playing GOD! Allot of developers get big heads and project managers who dont even KNOW what their developers built have the BIGGEST EGOS OF ALL! Don't try and sell something thats poorly built. Take the extra time to really put a talented and skilled organizer and planner on your team that builds web applications based on future growth, use, modification needs, and business needs. Your CLIENTS WILL LOVE YOU! It will take time and the extra time you took might not pay off now. As a case study for organization, Ive built around a dozen websites and applications, many very simple and some very complex with Contenet Management Systems and Flash and SQL Server backends for data. I RARELY IF EVER HEAR FROM MY CLIENTS....and neither does my team. When I do, its maybe every couple years when they want to EXPAND the web application....not destroy it for a new one. That says something very important about my project planning....
I TAKE EXTRA TIME TO DESIGN MY WEB PROJECTS FOR QUALITY, CONTINGENCY, GROWTH, AND USABILITY and trhe result is NO BUGS, NO CALLS, NO EXTRA COST TO MY COMPANY TO ADDRESS BUGS, and most importantly, MY CLIENTS COME BACK FOR MORE BECAUSE MY WEB APPLICATIONS ARE SO WELL BUILT! How many of us out there can honestly track that and see that. Get organized folks and design around quality code, architecture, simple structures, and usable and intuitive interfaces. One should be able to open up any web application they bought, look "under the hood" and know within seconds roughly where to find ANY ASPECT OF THE CODE, period! If your application is a maze of dll's, web pages, data and stored procedures everywhere, and proprietary set up and poorly documented configurations, and ill-designed navigation and user interfaces, then get ready to eat the cost in all the calls you get from confused and angry companies as the years go by. I argue NO business model can live long that way.
Now, to my main article. Now that you have read my point-of-view, you have a general understanding of my feelings about poorly built web applications, and websites that dont have the strength and organization to allow even simple changes and modifications as business needs change. I am going to give you my top ten list of things that make a rare few succeed. Trust me when I say, that only those that follow these ten things will be left 5, 10, 20, 30 years from now as IT needs and the Internet evolves. And that translates to only a handful of businesses still standing 30 years from now in this industry, I predict, with all the others disappearing into the shifting sands of time. Only those development companies with the forethought and wisdom to design such rock solid applications will survive! So, lets get to the ten things I recommend:
10 Secrets to Building Superior Web Solutions that WORK!!!
- Simple Architecture
- Simple Folder/File System
- Simple and Intuitive Design/Usability
- Simple Database Schemas
- Simple Code Organization
- Separation Principal
- Modular Framework/Structure
- Reliable/Popular Programming Technology
- Documentation thats Consistent
- Universal Organization of Whole Project
Ok, I'm going to just briefly touch on a few of these. The rest should be self-explanatory to you. All I can say is this. USE THESE OR DIE....and when I say die, I mean let your software die its slow death. Yes, its possible to build something GREAT, thats so universal in application and so reliable and flexible and organized and easy to use that all types of industries and groups widely adopt your software, and we all know what that translates to....MONEY! But more than money, writing good code and web applications means your future-looking considerations are helping millions of business people accomplish things that make their businesses run better than they did before. And for any develop, that should be your ultimate end-goal and source of pride. I know its mine!
Ok, "Simple Architecture" means that you need to stop and layout in your plans, in paper and digital format, your complete overall architecture for something before you begin. Where most developers fail here is in two ways I have seen....they think ONLY about the big plan, not all the little plans inside the bigger plan. By failing to start at the bigger plan and work their way into the "onion", they fail to see all the layers and how they interact and impact the whole. The second failure is when designers fail to keep such an architecture SIMPLE. Most software gets really complex fast because developers dont really CARE about organization. HALF of all the items in my list are developers and managers FAILING to ORGANIZE....and that goes back to what I said at the top of this article....failing to think about the bigger picture, in temrs of clients, and how their business might use, modify, change, and alter the product and how easy or hard that is, and how that translates to thousands of hours years from now, when expensive developers are pulled in to extract and sort out the mass of data and relationships in that data. Sure, some apps make that easy, like MS-CRM, but its not complete because most CRM will have forgotten some of the data and will not translate some of the original relationships so carelly constructed in the original product. My point being, that if you carefully think about your web application architecture, keeping it simple, yet flexible, and designing a flexible architecture that not only allows modifications as the program grows, but also when it needs to be scrapped for bigger and better apps, you will end up saving your client thousands of dollars, they never DREAMED they would be spending over the lifetime of the product. By highly organized teams thinking about designing rock solid web application software and given the time to put in that EXTRA TIME REQUIRED, iterations of that software performing for many years successfully in the market means reputation, and that means wide adoption, and that means expansion and even re-purchases by a growing field of clientelle for applications that have the goods to grow with those companies over many years. If your arch. is so simple to understand and so well desigend for growth and change in its initial architecture, from its complete layout, to its tiniest coded component, its possible to release software that actually is FUN to program against by other developers. Developer adoption requires SIMPLICITY. If thousands of businesses find it EASIER TO USE YOUR PRODUCT over your competitors, and tweak, and modify within its architecture (and even integrate with competitor products), you have achieved total SIMPLICITY OF ARCHITECTURE!
Simple file and folder design is the most abused system I've found. Developers create names and taxonomies for files and folders that dont match purpose. New people coming in require weeks and weeks to figure out where things are located when the time comes to make even simple changes.....all because of the overly confusing file and folder architecture. Microsoft Sharepoint is a perfect example of a HUGE MESS OF FILES stored in the Program Files/Common directory of a typical Windows 2003 server, after install. Its just a huge mess, and took our team of highly intelligent engineers WEEKS just to figure out where everything belongs. When I say where things belong, I am saying that when a simple web page needs to be changed, it should be SIMPLE to find the actual file that stores that html. Sharepoint, like so many, makes that a true nightmare....and they could have made their file and folder system so intuitive and easy and saved us the thousands we spent trying to sort it out!
Modular system is very important towards building customized systems. Any web application built today needs a separation of its structure, its presentaion layer, its markup or XHTML, and its back-end code. In addition, major extensions or additions to a core web application system of files needs to be presented via a "module". One good thing I've seen more and more of in current apps is the use of a database-driven module system, where users can simply upload or add a set of files to a folder, and the database stores a reference to those added systems, and they are immediately in the new system and ready to use. This level of integartion, though, doesnt stop at the module level, but needs to be carefully conctructed in the code or object class level of the back-end code, in the markup in temrs of headers and footers that are located in one file, but attached as "includes" or "controls" into every page. The use of such "instances" should permiate ALL facets of the final web app, and combined with a very simple and easy to use file and folder system that reflects the overall structural function and architecture of the site, means ANY DEVELOPER CAN OPEN UP THE CODE AND WITHIN A REASONABLE PERIOD OF TIME MAKE A QUICK CHANGE AND ITS DONE, hassle-free!!!! The ability to add module INSIDE of modules, and then allow the customer to easily build their own modules in an open-source fashion with little technology training beyond say simple markup languages or simple xml, means again, universal adoption, which is the end-goal!
The "Separation Principle" is about designing web applications where the presentation in terms of Cascading Style Sheets is stored in a series of linked styles sheets, which in turn are separated from the markup which needs to be XHTML (as of 2005), which in turn is separated from client-side scripting (Javascript), which in turn is separated in the code from the back-end or server-side code. In .NET this is stored in the "codebehind" page. If you also separate the markup structurally into includes or controls, so that the header, navigational elements, footer, and reusable content is also stored separately, then you will find you have a very very efficient carved up site where content is separate from presentation which is separate from the server objects and scripts that control data driven parts of the product. This may sound obvious to you development experts, but I cannot tell you how many developers and projects I have seen where the senior developer left out these simple features. By not carefully separating out all these features, the time it takes to normally change say a logo in the header of a web page, or a navigation tab, now can take hours or even days and weeks if you try and change every page in a project. Again, .NET allows really powerful server-side codebehind and class object management, but poor markup control. If you practice good clean cutting-edge XHTML and CSS for your design elements, then combine .NETs usercontrols for each piece of your page layout, you have complete power over the whole site and making even enterprise-level changes to your web applications now takes seconds instead of weeks! But more important than this feature, such separation makes it EASY FOR YOUR CUSTOMETS AND USERS TO CUSTOMIZE ANY FACET OF THE PRODUCT!
Reliable/Popular Programming Technology means choosing a technology that is both powerful today and widely adopted, as well as MOST LIKELY TO BE AROUND TEN YEARS FROM NOW. Microsoft.NET is an example as is PHP of two technologies I would bank on! Thats right....you BETTER worry about that fact, as it has meaning! You want to choose a technology that has those features and is strong and popular enough to survive the winds of change. They may change the landscape, but your solid foundation will be set in stone if you choose a technology who survives in some form in the future, so that older iterations of your web application continue to be supported as the years go by and your customer base grows...
The Failure of good documentation is prevalent in the open source community and one of the sources of its clear failure. Without consensus, and consistency, those technologies eventually die. One exception has been the remarkable recovery of Mozilla and its remarkable browser, all built on a very consistent and well-documented developement community and model.
Lastly, there is "Universal Organization of the Whole Project". Thats a very vague and obscure concept without much importance it seems. But I put that last, as its one of the things most software companies fail to do. If you look at the big players, like Apple, Microsoft, andf Symantec, all of them do that very well....they maintain increasing levels of organization, product organization and total integration of all company concepts, marketing, code, design, branding, and even personell around their software. The software takes center stage, and is almost the organizer for the company. Ive been very impressed with how all the big players refuse to take for granted careful and time intensive organizational practices in developing their web app products. Some clear failures like Sharepoint exist, but many successes eclipse those. Smaller companies tend to do sporatic organization....usually in the form of the company leader giving orders and setting goals that are not carefully given the leadership or required time and manpower to implement them. Such organization is usually maintained by the knowledge workers themselves who out of desporation take their personal time to organize factes of their jobs and company assets, enough to make their tenure at the job liveable and efficient. But company-wide organization is usually limited to financial and collateral and project documentation....not a consistent company policy...which takes TONS of time and thought, and thus costs money. Unfortunately, that translates into infrastruture and development teams creating great works, but the software never attains teh reflected organization across all facets, so needed to see wide adoption. Thats again, explained above. But thats the main point of mine here.....that ORGANIZATIOn needs to permiate all elements of a company, its tema, its managers, and especially its web application/software development practices, in order to attain success with those apps. Organization is about "control" over every facet of something, and knowing exactly how and where and why code in a web application is working or not working well, or how a small company is approaching its long term goal of selling more software to a saturated competitive marketplace requires knowledge and efficiency beyond art....its about science, and very strict science! Its about knowing exactly what happens when a client presses the wrong button in a certain part of an application....its about where to quickly look if a certain feature of your sofwtare breaks, and fixing it in seconds, rather than weeks....its about analysing your client base and changing your software to meet that demographic....its many people in an organization all knowing exactly where everything is, where everything is working great, and everyone knowing what is a work in progress. If you web application developers dont know, how can you? Not knowing means something could break for your client, and then thats when not having a universal and total and consistent approach to organization will end of biting you in the foot, and spell doom over the long haul to your carefully built web application projects.
So, follow my list....and think about my words, think about organization, and think most of all how to make your web applications rock solid, highly organized, complex yet simplified reliable business applications that your clients will increasingly rely on to support their changing businesses. Reliable technology that is easy to use, easy to program, easy to modify, and easy to add modules to, which lasts years and years with the flexibilty to grow with the company as its needs grow, is web software the world so desperately needs right now and will certainly crave when such a product is someday built!
- Mitchell Stokely, USA
