How do web developers think?

written by Paul Cowan, Lead Developer, Wishlist Holdings

How do you define good code? What do you look for?

"Good code" works toward achieving five things. Apart from the obvious "functional correctness", the rest are:

robustness
performance
security
maintainability
extensibility

Each of these is important, regardless of whether you're coding for the web, application programming, or anything else. Coding with an eye to each of these is often harder, and more time-consuming than just slapping something together.

In fact, in my experience good code is just as quick and easy to write as bad code.

If you're trying to evaluate whether code is 'good' or not, these 5 points are a good place to start:

Robustness: will this code cope with everything that can be thrown at it? Edge-case testing is a vital part of this, but as far as spotting good code, it's usually pretty clear whether code is written only to cope with best-case scenarios or whether some thought is given to handling invalid data, unforseen errors, and malicious input.
Performance: this is probably the hardest to judge, particularly if you're not intimately familiar with the fastest way to do things in a given language or environment, but code which doesn't make unnecessary or duplicated database or function calls (a surprisingly common fault) is a good start. Remember that improving performance often comes at a cost, impacting negatively on all four other goals; shaving 0.1 seconds off a little-used function call, when it makes the code twice as hard to maintain, is most likely not a good tradeoff.
Security: the easiest way to evaluate someone's attitude to security in a web app is to look at whether they obey the fundamental rule of information processing security: don't trust anything you didn't create yourself. Does the code assume that everything passed by the browser is valid? Does it even check? Good code should not just assume bad input, but actively malicious input. It's usually obvious if coders have considered this. Coding securely is something that's very hard to do well, but for most systems, it should be non-negotiable.
Maintainability: A lot of good programmers say that commenting code, for example, is pointless, because well-written code is perfectly understandable on its own. They're right -- but unfortunately, very few programmers can pull this off. If you can look at someone's code, and tell EXACTLY what it does without looking at the comments -- you've got a keeper. Hire them immediately. If you can't, but the comments are enough to make it clear... well, that's often as good as you're going to get anyway!
Extensibility: Code which sticks exactly to the functional spec is fine. However, functional specs often change over time, and code which contains masses of hard-coded, inflexible business logic or constant values can make life a pain for the poor guy who has to take over.

How important are standards and which do you follow strictly?

Standards are crucial for any project, particularly as they have a drastic impact on all five of the goals given above (especially the last two). Standards get even more important as three things increase: the size of the coding team, the scope of the project, and the age of the software.

The more important standards we have in place

Consistent function naming. Having to trawl through 100,000 lines of code to find that, despite the fact that there are functions called DisplayName(), DisplayAddress(), and DisplayTelephone(), the fax function is called ShowFaxNumber() wastes everyone's time and directly impacts the extensibility and maintainability of the code.
Sensible naming of variables and constants. Having code that contains loop counters called called "Jedi" and "ElvisRaces" (real-world examples, alas) might be fun, but it makes the next person to have to take over your code feel like hunting you down and murdering you.
Don't hard-code anything. With very few exceptions, if it's needed in a calculation, it's worth making into a named constant. Not only can tax rates change -- why code (tax = price * 0.1) in a dozen places when it might change? -- but it makes code much easier to read too. When looking at "result = input * 0.7854", the meaning might be obvious to you. But will it to the next person? Or you in three years? "result = input * (PI / 4)" is a much better bet.

How do you as a coder feel about wysiwyg development tools like Dreamweaver, Visual Studio, Front Page etc?

I'm biased against them, but I haven't used one in years. If people prefer to use such tools, then good on them, but if they're on my team, whatever tool they use had better produce code that is AT LEAST AS GOOD as would be produced by hand, and not a pennyweight less.

My standards might be more exacting than most. However, bloated, inefficient HTML makes life worse for those who have to maintain it, AND for the end-user who has to put up with greater download times.

I prefer the control gained from coding HTML by hand. I find the maintainability benefits far outweigh whatever productivity gains there might be. Others might have different opinions, but be sure to evaluate any such tools very carefully indeed.

How should coders/developers be briefed?

There are two common (and infuriating!) flaws with briefs given to developers.

The first, obviously, is that which doesn't contain enough information. The perfect brief should detail every possible input and output required. If you hand a developer an incomplete brief, you should assume that everything that's not specified -- potential error messages, exact layouts -- is up to the developer. And if you're not happy with what they come up with, then they'll consider it very much your problem for not briefing them thoroughly.

That said, there's a flipside. If a brief is painstakingly complete, it had better be produced by someone with an intimate and exhaustive knowledge of the technology available, the end-user's needs, and any usability issues. A thorough and detailed brief is useless if the solution it details isn't possible, isn't usable, or doesn't cover all the client's needs. If you don't fully understand what you're specifying, getting bogged down in details wastes everyone's time.

You're a programmer for an online company, what are your thoughts on Flash, fixed page widths?

Flash: Flash is a great tool that is, in my opinion, vastly overused. While it has improved a great deal, Flash still suffers from usability problems. Replacing HTML with flash to LOOK BETTER is rarely, if ever, a good idea.

While it's not a fault of the tool, everyone using Flash needs to ask themselves not only if they need it, but if there are actually tangible benefits to forcing the user to understand a totally new navigation system, some sort of funky custom scrollbar, non-obvious links, and so on. Just because you CAN do something in Flash doesn't mean you should.

Fixed page widths: This is clearly a personal issue, but I run a large monitor at a high resolution. I have no desire to see half my monitor wasted by white gutters down the side of a page. Fixed-width aficionados bleat that "lines longer than 16 words are harder to read", or somesuch. True. But usability is about a lot more than readbility. Usability is also about being able to see all the information you need quickly; people rarely READ web pages anyway, they scan them. I'd rather see more of the page at once than have other people's readbility ideas forced upon me. If other people don't like that, then they can resize their windows.

Do you code from a user point of view or from a technology point of view?

Usability is just one factor in how to develop a web application, but it's one that is massively underrated. If you can shave a minute off the average user's experience, people will find the site proportionally easier to use.

How much difference could this make to an ecommerce site for example? How much difference would it make if the savings meant 1% more people finished their orders?

If you have 100 orders a day, that's one sale that hasn't slipped away. How much effort does it take to shave off a minute from the purchase process? Probably much, much less than you'd think.

Platforms: What's your view on ASP, ASP.Net, Java, PHP, Cold Fusion.

For any sort of large-scale system, object-oriented coding, IF DONE WELL (and it's much easier to do badly) is almost certainly more maintainable and extensible. Assuming you have the talent to do it well, it's definitely the way to go. For .NET vs Java, it really is a personal decision, and I think the differences between the two are overrated.

The ability to avoid vendor lock-in is a big plus with Java, particularly now that Java itself has advanced so much that the platform-neutrality is now no longer nearly as much of a hindrance.

If you're an MS shop anyway, though, I don't think the advantages of Java are necessarily much of a factor. Both technologies are changing so fast -- Java 5 brings a whole bunch of maintainability improvements, and remember the .NET architecture is only just now approaching version 2 -- that it's very hard to make a call on the long-term positions of either. Personally, I think both are here to stay.

PHP + CF I can't really comment on that much, but don't underestimate the value of a readily-available resource of eager people throwing their all into free software. You'd have to have your head in the sand to not see that free and open source software is starting to hit the big-time, and PHP is one of the best examples.

What are the challenges of working with designers?

The biggest challenge is working with those who don't realise that designing for the web is different from designing for print. It's a simple lesson, but one that many don't get.

Insisting on your precious Pantone colours looking EXACTLY the same on everyone's screen, and that your layout is pixel-perfect compared to the print brochure, is just not going to happen.

You wouldn't insist that your logo looks the same on everyone's television, regardless of their brightness, contrast, colour settings or TV size. However, for some reason, many designers seem to think they CAN do this with the web, despite the fact that there's even more variation here.

Paul Cowan

Paul Cowan is a web developer whose typical workday includes 48% coding, 28% troubleshooting, 15% architecture and software design, 12% requirements gathering, 9% database maintenance, 8% banging his head against his desk, and 1% checking his addition. His areas of interest include usability, security, performance, and the eating of extruded snack foods. His turn-ons are walks in the rain and candlelit dinners; his turn-offs, combine harvesters and milkmen. His personal website can be found at funkwit.com.

Back to other Opinions.