Eric DeLabarWeb 2.0 from a Web Purist and J2EE Developer

One day a small business owner, known to dabble in the do-it-yourself arts, was reading the visitor statistics from the website that his nephew had made him. Disappointed by the long page loads, low traffic, and cross-browser inconsistencies, the small business owner went to his kitchen for a glass of water. He turned on the faucet and nothing happened. A minute later, water started pouring out from under the sink. Quickly, he turned off the water and rushed back to his computer and looked up the name of a local plumber, he called, and had a plumber dispatched immediately. By chance, he also saw an advertisement for a local “low-cost, satisfaction guaranteed, web developer” and called him as well.

Twenty minutes later, they both arrived. Apologizing for the timing and offering a cup of coffee, the small business owner asked if the web developer wouldn’t mind waiting while he got the plumber started. The web developer, figuring he’d only had six cups of coffee today, decided a little waiting was not a problem.

The small business owner took the plumber to the water shut-off valve, and the plumber quickly shut it off. While discussing the solution, the small business owner told the plumber that he would like all of the pipes from the valve to the sink to be replaced with PEX pipes instead of the existing copper. Concerned, the plumber warned that there was nothing wrong with the existing copper pipes and that he was unsure if PEX was even allowed by local commercial building codes. The plumber even offered to first double-check the codes, but in a hurry to get back to the web developer before he drank all of the coffee, the small business owner told the plumber to just do it. He blindly signed the contract, completely ignoring the written warning about violating building codes, and left the plumber to do the job.

Relieved to have one problem scratched from his list, the small business owner left the plumber and returned to the web developer, who had already drank all of the coffee. Annoyed, the small business owner began making a new pot of coffee while explaining the problem with his website. Hearing the same thing a thousand times before, the web developer began his speech about web standards, usability, accessibility, and information architecture. Within seconds, the small business owner’s eyes had glazed over, and he began ignoring everything the web developer said.

A few hours passed. The plumber finished the job, the small business owner signed the web developer’s boiler-plate contract with 100% satisfaction guarantee, and both the plumber and the web developer left the small business owner to finish his list of things-to-do.

About a month later, the web developer returned to the small business owner’s office to show him the finished product. Coincidentally, the city building inspector arrived at the same time. Learning his lesson about web developers and coffee from the last visit, the small business owner told the building inspector that the work was done down the hall in the first room on the right, and left him to his job.

The small business owner and the web developer went to a computer and the web developer showed the small business owner the finished product. Unimpressed by the lack of motion, flashing, and changing colors the small business owner said that the new site was “nice, but needs something.” The web developer, who truthfully knew this was coming, began regretting his 100% satisfaction guarantee. By the time the small business owner was done stating his “satisfaction requirements,” the site had lost its information architecture, the typography was small and low-contrast, the flash-intro was back, and bigger than ever, and the back end programming was changed from a lightweight CMS to a large enterprise framework that the small business owner’s friend had heard about at a trade show. Concerned for his portfolio, but tired of this particular client, the web developer left the small business owner’s office; defeated and hoping to just get the job done as soon as possible.

Glowing from his victory against the tasteless web developer, the small business owner went down the hall to find the building inspector. The building inspector was sitting in the corner of the room finishing up his report on the plumbing changes. He looked up from the paper and told the small business owner that all of the PEX pipes had to be removed because it was against code in a commercial building. Aghast, the small business owner quickly called the plumber to chastise him for performing such a blatant building code violation. Unimpressed, the plumber simply referred the small business owner to section 4c of their signed contract where it stated that the small business owner had been informed of all building codes to the best of the plumber’s knowledge and that any specific requirements performed by the plumber per the customer were the responsibility of the customer. The plumber also stated that he would be glad to come out and replace all of the PEX with brand-new copper, under a brand-new contract.

About a month later the “improved” website was live and still suffering from the same long page loads, low traffic, and cross-browser inconsistencies. The web designer however, had already folded his company and taken up a new career as an apprentice to the local plumber.

The Morals

Mostly everything we do as web developers is according to some specification or recommendation, but it’s still very easy to ignore them all and still produce a “functioning” website. We compete in an amazing marketplace against everyone from the boss’ nephew to Fortune 500 companies. Because of this, highly skilled web developers working at small companies or even as freelancers often make stupid promises, including 100% satisfaction guarantees. These guarantees do not help anyone because the client is rarely satisfied, the end result isn’t worthy of the web developer’s portfolio, and none of the original problems have been solved.

Plumber’s have the law, the union, air-tight contracts, years of collective experience, and the fact that there’s no such thing as WYSIWYG plumbing software to keep the average Joe from calling themselves master plumbers.

The Soapbox

I’m not sure if it’s a question of attitude, experience, or the fact that there are parts of the plumbing profession that literally stink, but people rarely tell a plumber how to do their job, and I doubt many plumbers would even let someone if they tried. To the same extent, a plumber’s work is usually not up for scrutiny in the public eye, in fact other than in basements and under sinks, it’s rarely even visible to the proerty-owner’s eye.

So what’s my point? With the amount of very talented web developers and designers available world wide, the web has the potential to be a very beautiful, very usable, and very accessible place. However, the web wasn’t build by graphic artists, typographers, interactive designers and information architects, it was built by tinkerers, inventors, and do-it-yourselfers, kind of like the first indoor plumbing. We have a long way to go before there are laws requiring best practices, and professional reputations that allow us to say “this is the way I’m going to do it, and it’s non-negotiable.” But that doesn’t mean we should stop educating our customers and return to table based layouts and excessive use of the blink and marquee tags. It means there’s a light at the end of the tunnel. Until until we reach that time, sell the fact that you’re an expert and not the fact that you’re guaranteeing satisfaction. Let your work speak for itself, a well-designed and well-implemented site will just work and will lead to a satisfied customer, whether or not it’s been guaranteed in writing.

Every time I read a new post on Andy Rutledge’s blog Design View I feel the need to comment. Andy has made the decision to not allow comments on his site so instead I’ll comment here. The latest article on Design View is about Pre-Bid Discussions, in it Andy explains how his company turned down a $50/60k project because they could not see the project succeeding according to their terms. For the fact that he turns down projects for integrity reasons, I applaud him! As far as the article, his analysis and process are insightful and I’d love to be able to use them, but for now I’d just like to expand on them.

I would like to add two questions to Andy’s list of five, and I’ll continue with his format of stating the questions and then coming back to them, so numbered for reference:

6. Am I or is my team able to develop with the technology stack?
7. Would I invest my own money in this project?

As Andy laid out in his article, these are questions that should be asked during the pre-bid discussion. There is nothing worse than blindly responding to an RFQ and winning the job only to find out that the client does not want somebody to help them implement a solution, they want somebody to blindly do their bidding without question. But I digress, ladies and gentlemen, the questions.

6. Am I or is my team able to develop with the desired technology stack?

I have seen this question extract chunks of flesh more times than I can count. Most programmers will tell you that programming is programming and the difference between languages is small enough that given a few weeks a real programmer can learn any language. I’ve said it myself, and I thoroughly believe it. However, I’d much rather have the end results from a programmer who’s an expert in a language or framework than a programmer that only learned it a few weeks ago. Think about these questions when discussing the technology stack:

• What version of X Technology are you using?
• Do you have internal coding standards to which we’ll need to adhere?
• Has something been developed and deployed to this platform before?
• Will your team be interacting with our code directly?
• Will we be interacting with your team’s code directly?

These questions are more technical than Andy’s, but they’re vital for determining the overall scope of a project which is necessary for placing a bid. Software versions can make huge differences. I whole-heartedly agree with coding standards, but if the standards say no open source or external code you may be up a creek if you rely heavily on Jakarta Commons. Is this stack even possible? Sure, the bigwig sales guy said a heterogeneous solution of Company A’s ORM and Company B’s DB and Company C’s development environment would work, but have you seen it and can you get support for it when it fails? Finally, if you’re co-programming this project with the company, will they be changing your code? Will you be changing theirs? What does their programming team think of bringing in outsiders? How long will it take them to make a code change that you need and who’s responsible for making up that time? Think about who’s making the rules, who’s following them, and who’s enforcing them.

7. Would I invest my own money in this project?

Nothing will kill the morale of your team like working on a project they think is doomed to fail. I really hate to tell you to judge somebody else’s ideas, and 9-chances-out-of-10 I’d take the client that has a few million in VC-backing, but sometimes it just doesn’t make sense. This especially comes true when the sales pitch for the idea starts with: “It’s like some-other-app but…” Let’s all face it, twitter is a huge surprise and everybody loves it, but that does not mean “It’s like twitter but instead of other users subscribing to your tweets you get to publish your tweets to the people you want to see them,” will ever make billions. If they’re not the first, the free, or the best, let somebody else implement the failure. I guess this is a bit of a sore spot for me personally, but ignoring that, here’s some questions to ask:

• Have you done focus groups or would you like us to help you do them to support the feasibility of this project?
• How do you intend to monetize this idea?
• How do you intend to build your user base or generate buzz about this idea?
• What happens if the users adapt your system for some other use beyond or in contrast to your initial plans?
• What is your reason for starting this project?
• What is your goal, how do you define success for this project?

No audience, no plans to obtain an audience, and no way to make money are surefire signs for failure. If you still like the idea and you think you can help, at least make sure you get paid up front. The next few really don’t have right or wrong answers, but the foresight to know that the agility to adapt might be necessary is a good thing to have. As for reasons, you might want to get out your moral compass, if it’s for world domination, drug trafficking, destroying the ozone layer or patent trolling you may not want your name attached to it as the implementor. Finally, it’s good to know the client has a plan, how can you define the success of this project if they can’t.

My Main Point

Like Andy, I’m definitely saying that if you establish your own rules up front it will make it easier to say no to a job no matter how big or easy is might seem. Unlike Andy I will say that I understand the necessity to bend these rules on occasion to at least keep your team busy, if not productive.

But let me stress the “on occasion” part. It is not good to be the bargain basement whore of web application design. Your reputation can mean the difference between finding jobs and having them find you; or playing the part of the expert-consultant or errand-boy slave. Your portfolio, client-list and case studies can speak worlds about your company, but not if every client that’s ever worked with you has gone out of business or insists on not being on the list. Even a big-name client means nothing if they’re using some propriety or ill-conceived tech-stack your team would rather quit their job than use.

Think about it. Make your choice. Reread the title.

Let’s pretend, be it from VC’s, angels, or remortgaging your house, you’ve come into some investment capital and are looking to build a web application.  Here are my top 10 ways to spend every penny of it and still fail miserably.

1. Over-complicate your concept

   So you have an idea, a good idea is a simple one. Take your core concept, develop that and only that, and get it out to the public. Run a closed beta, or even a public beta, and see if there’s interest. You and your investors may think it’s the greatest idea in the world, but if nobody else does it’s not going to make any money. Before you consider your user interface, chew on this for a while.

2. Buy tons of expensive hardware and software

   If you’re taking my advice on number one, this one is easy. A simple concept with a simple implementation doesn’t require a quarter million dollars of hardware and software licenses. When you start out you won’t have tons of data, or users, and if your app is programmed correctly I would hope you don’t have tons of processor load. Try out shared hosting, or maybe a year-long contract on a dedicated server, or if you must buy or lease hardware, acquire a simple 1U machine or small cluster and see how it works. Build your app on a platform that scales well, and design it to be scaled. Hardware gets cheaper by the day so three months down the line you’ll get more disk, RAM, and gigahertz for less money and it won’t all be sitting at 99% idle while your user base is ramping up.

3. Develop to a functional specification

   A functional spec looks great on paper, but sit down and think about it. Can you honestly tell me that you can think of EVERYTHING your app needs to do right now? You don’t even know what your users are going to think of it or do with it, they could end up using your application for something you never even thought of, and your entire business plan my have to evolve to accept it. Consider agile development, you’re probably going to pay developers by the hour and have to spend time working with them, but you can adjust as necessary when you see something just isn’t working. Agile development offers a finished product that is exactly what you need now, not exactly what you thought you needed three months ago. It may even save you money if you decide to make radical functional changes or that your app is perfect without feature A. Remember point number one here; your app is done when people love it and use it, and you won’t know that until they’ve had a chance to put their hands on it. If you’ve still not sold, read this.

4. Waste time

   This is the internet, first to market gets the buzz and everyone else is a copycat. The more time you waste with things like functional specifications and bulky frameworks or languages, the higher the chance somebody else is going to do it first.

5. Ignore the early adopters

   Web 2.0 applications live and die by the blogosphere, get your beta out there, make sure some of the movers and shakers are interested, and listen to what they have to say. If they love it, your lucky, if they don’t, listen to them, if they hate it, cut and run. If the blogosphere doesn’t generate any traffic for you it’s pretty unlikely that any other advertising will. Geeks try things first, geeks tell their friends and family if it’s worth it, but geeks may also tell you what you can do to make things better, and if you listen, they’ll probably tell even more people because you did.

6. Ignore the experts

   Maybe you’re not a web developer by trade, so you hired some company to help you develop this application; you’ve hired them, they must be good so listen to them. Chances are they’ve done more of this then you, they understand the technologies and the medium, and they just know how this stuff works. You hired them, trust them, don’t tell them how to do their job.

7. Get more investors

   If you’re looking for more investors I’m assuming you’re looking for more money, and I have to ask “why?” Is there something wrong with your business plan? Did you start with less money than you thought you needed, or are things going badly? Investors take wooing, possibly traveling, these things cost money, consider cutting the fat from elsewhere first and don’t waste your resources.

8. Use buzzwords

   Buzzwords are expensive. If you’re not a developer and you walk into a software shop and start throwing around AJAX and Web 2.0 you’re bill is going to go up. Let the shop tell you when AJAX is appropriate, let the shop define Web 2.0, because it’s not just animations and shiny buttons. You won’t impress anyone with how well you can use buzzwords in a sentence you’ll impress people with how well (and appropriately) you use the underlying technologies in your application. If you want to use buzzwords, try usability, accessibility, and progressive enhancement, you’ll get more credit from an informed developer and your application will be much better for it.

9. Hire too much management

   Managers are expensive. They suck up time with unnecessary paperwork, meetings and bureaucracy. Spend you money on quality developers and let them do their thing.

10. “Improve” somebody else’s idea

    In my experience, first-to-market usually wins, hence rule number 4, but if you want another opinion, read this. Basically there’s room for three, the first, the free, and the best. If they already exist you better be able to cover the free and the best or maybe just the best but if you have an incredible marketing team. Users get entrenched and usually won’t switch, so if your market is saturated, it may be a good time to consider a new idea.

That’s my two cents, if you like it, listen to it. If you want to use my experience and work with me, please contact me. If you disagree, comment, I want to hear why.

To state for the record, the opinions expressed in this article are those of the author and not his employer, while his employer may be willing to work under different terms, this is not their SOP.

I recently finished a “Members” section of a website for a local non-profit. The primary user base was small, (less than 100) so I didn’t spend a lot of time on building a robust user management system. Basically, a user would access the site, request a login by entering a username, password, confirm password, first name, last name, phone number, and email. After which an admin user (i.e. yours truly) would be notified, log in to the site and approve the account if they knew the user.

Here’s where it gets interesting. Of the 10 users that have signed up so far, 5 of them have used a space character in their username. Is it a problem? No, not in this instance, but I found it to be interesting user behavior. I personally have not tried to use a space in a username in as long as I can remember, but I can’t tell you why. I would assume that a long time ago when I created my first online account, (an AOL screenname if I remember correctly) a space was simply not allowed.

So what’s the point? Simple; users do things you may not expect, and you may not expect things for not-so-valid reasons. (Face it, how AOL did things in the mid 90’s is probably not a best practice.)

On a related note, 3 of the 5 members who used a space character in their name have already “forgotten” their username; they actually didn’t forget it, they just misunderstood the username field to be a full name field, and simply entered their full name on the registration form, and then didn’t know what to enter in the login form. So, the next build of this site will feature much more descriptive, cork’d-like forms, in hopes of solving these problems in the future.