Alex Burr

“Professionalism” in Web Development

Originally published Thursday, December 30, 2010

Recent discussions, both in Tweetspace and the Real World, have caused me to think carefully about what behaving “professionally” means when it comes to the industry of web development. Here is a summary.

Lovable developer Andy Rutledge has been tweeting quite a bit on this subject lately. Andy is not know for subtlety in his statements, but in general I think I agree with his assertions (he can certainly correct me if I’m mistaken). [UPDATE: Andy has since published a book about this subject.]

I’m moved to explain my POV on this partly because I have encountered several individuals in my career who have used the term “professional” to describe a particular person or situation that is “favorable” in some generic white-collar way (wears a tie, agrees with superiors, customer-oriented, delivers quick results), or “unprofessional” to for a person or situation that is “unfavorable” (sloppy, obstinate, critical, ill-mannered).

Interestingly enough, many of these individuals have been placed in positions of leadership or management over web developers or web development projects, and have a complete misconception about their role or professional standards.

There are several main aspects of behavior that I think define professionalism when it comes to web development, and each is built upon the last. I’ll explain them now, but here’s a hint: They don’t involve whether or not you wear a tie.

  1. Professional Standards
  2. Professional Quality
  3. Professional Process
  4. Professional Operations
  5. Professional Tools

1. Professional Standards

Professionalism is about how you operate. And it all starts with the standard that you set for yourself. To use an analogy, medical doctors hold themselves to a certain professional standard: That all of their decisions be made in the best interest of their patient. Sometimes, this involves telling the patient something that they don’t want to hear, despite the fact that the patient is paying them good money. This is because the doctor’s role is not a service, it is a consultation.

You’ll never encounter a situation where a patient walks into the doctor’s office and says, “Hey doc, I’m going for the World’s Fattest Man record, so I need to gain 250 pounds and I just need you to put together a diet for me”. Well, maybe on the Simpsons. The doctor would refuse to perform this service because it is not in his patient’s best interest to gain 250 pounds; the weight gain would make the patient less healthy and is the opposite of the doctor’s job.

Following this professional standard has garnered doctors lots of money and respect.

Now, the web developer’s professional standard is very similar: All of our decisions are made in the best interest of our audience. I cannot emphasize the word audience enough; I specifically did not use the word customer. This is a little bit tricky, because most of the time our audience is not paying for our expertise, our customer is. It’s sort of like being a pediatrician: Your patient is a child, but the person paying for your work is their parent, and it will be actions of the parents that determine the child’s state of being. So the pediatrician finds herself in the position of having to tell someone who is not her patient what to do, and she may be at odds with the parents’ expectations.

Fortunately for the pediatricians, they are already doctors, and have the accompanying money and respect.

We don’t have it so lucky in web development. Many customers are under the misconception that they are paying for our labor and not our expertise. Therefore they will have a product or solution already in mind and just want us to turn it around for them with no trouble. Unfortunately, their concept is usually half-baked, leaving out crucial details in the user experience (“How will they log in? You do realize that just having basic user management functions creates a geometrically more complicated piece of software, right?”) or is just downright not the answer to their audience’s problem.

When the developers attempt to steer the project back on track, they may be met with disbelief or outrage rage from the customer. Unfortunately the customer didn’t realize what they were getting into: No professional developers will ever just “make” the dumb website or application they wanted. We will build the website or application that their audience actually needs instead, since that’s our professional standard.

2. Professional Quality

The next aspect of professionalism is the quality of your product. This makes easy sense to me: if your standard is that you meet your audience’s needs, then your product must be of highest quality to meet that need.

This is the one that most developers would probably agree with. If your site is built on static content in .shtml files with tables for layout and flaming skulls in your logo, most web developers would agree that it is unprofessional. Similarly, if your complicated web app is full of bugs, only works in Internet Explorer 6, and constantly forces the users to scroll horizontally to find the button they need to press all day, it is unprofessional.

In the above scenario, the customer’s self-designed solution usually comes out as one of these junky hack jobs. Ergo, you can’t create a professional-quality product if the goal of the project is to meet the customer’s wishes and not the audience’s needs. Which leads me to…

3. Professional Process

The only way to build a quality product is to follow a quality process.

Outwardly, for the freelancers and customer relation-types, this means guiding the customer through a proper project life cycle. And the very first step in the cycle is asking two questions: “Who is the audience?” and “What does the audience need to accomplish?“. (There’s also “What’s your budget?” but I won’t go into that.)

If there are not clear answers to these questions, then there is no way of meeting the professional standard and the project is doomed. Similarly, if these answers change two days before launch, there are problems. If the customer can’t answer the questions clearly, they are going to force a non-quality product, and it would be unprofessional of the developers to continue on the project.

Inwardly, this is about project management. Are you developing on a waterfall model? The unified process? Agile or SCRUM? Do you do formal use cases?  Are tasks and milestones clearly defined? Are there mockups done and some sort of functional prototyping? Are bugs and features requests managed in a software solution? Are your coders doing unit tests?

If your projects do not follow some sort of pre-defined process (and you don’t need to reinvent the wheel here) you are not being professional. The complexity of the process can vary from project to project (a small brochure-ware site might not need use cases or functional prototypes, for example) but there’s always a process there. Throwing everything together, not getting answers to questions, forcing revisions on a whim, or skipping important (but non-rewarding) steps like load testing, needs assessment, or usability testing results in a low-quality product.

There are really no excuses for those problems. The client relations side has to deal with potentially disagreeable customers who can withhold money, but internally, failing to manage projects properly is just lazy.

4. Professional Operations

This one is all internally focused, so it’s last on the list. But if follows the same logic: You can’t create a quality product without a quality process, and you can’t follow a quality process if your organization is a mess.

Firstly, recognize that product development takes more than one person. Now obviously I’m not going to say that more people = faster results, this has been disproven so long ago that it’s obvious now. So actually, there’s good indicator: if you are managing a software (or web) team and keep adding random human resources, you’re pretty out of it and have to learn about the industry you’re in.

However, good products require a well-rounded team. Regardless of the size, it’s the roles that are important: How many layers are there on the team? Who is designing? Is the designer responsible just for graphics, or should he be writing markup and styles?  Is the back-end coder responsible for database design? Is the front-end coder responsible for the view patterns or just the client-side script? Who is tech lead? Is someone dedicated to server administration? Who is running builds? Do individual developers have to merge and branch source code? Who is leading user testing? Are there dedicated bug testers?

This aspect of team specialization is absolutely required as a team’s responsibilities increase. Plus you have a higher likelihood of overall product quality: Why have a butt-ugly interface design done by a programmer when it could have a fully-great design done by a specialized designer? And why make someone who’s great at design write buggy unstable code when there’s a talented programmer right next to him? In a smaller organization (less than three people) this can be difficult (and the freelancers have to do everything soup-to-nuts), but the bigger your team is, the easier it is to stratify. Take your existing team and restructure them according to their strengths. It might not even need a formalized change in job descriptions or HR codes, it can just be an internal practice that certain team members are recognized as owning certain layers of the process.

Interestingly, although this could be the easiest step to take towards operating professionally, it is the one that I’ve seen meet the most resistance from managers.

5. Professional Tools

This is for the executives and managers of web groups: Please invest in your people. You cannot expect to start taking orders for “a really awesome iPad app” if none of your developers own an iPad. Just like each of them owns a computer (which you provide) and they are on the web all day becoming familiar with the latest ideas, they need to own iPads and be regularly using them before they can be expected to understand the idiom enough to produce great products for it.

Fancy gizmos are the extreme example, but there are other resources out there your people need. It’s ludicrous to see web teams working from an old copy of “HTML for Dummies” on a Pentium 4, making changes directly on the production server. The web changes very fast, and the audience expectations for product quality changes with it. Therefore your team needs to be able to keep up. Buy them books that they identify as helpful. Get them a  development server (or a whole farm). When they say they need a license to something like Balsamiq Mockups or FogBugz, or a subscription to Typekit, it’s not that they are greedy little punks, it’s that they are trying to produce a higher quality product and need higher quality tools.

Why? Because the audience expects it. And it’s unprofessional not to deliver.