Quality in Web?

I’d been thinking about quality in web these days.  What supports a webdeveloper writing quality rich code? My result is a list with five central thoughts. This list could have been a blast of ideological presumptions. However, that ideological approach is as hard to defend as it’s general. So I tried to focus on the well-known but neglected facts. Feel free to round it up!

1. Exhaustive Concept, Straight Tasks

“Nothing is as vain as hiring a captain to sail to nowhere. The journey will never end.”

That’s also true for software. Sometimes I feel like sailing simply nowhere. It should be as naturaly as breathing to start software with a written concept. If no concept is on board the vessel, there’s no quality. A specification is defining what quality of function is and how to achieve it. This makes it essential to spend energy in it. My experience is: The less existent a concept was, the more iterations it took to remodel the software. With remodeling, bugs appear and quality exhales. Not having an exhaustive specification of software is to displace the discussions of functionality between customers and managers into the source code. Imagine your last meeting with all parties discussing the needs and demands: That’s how software will look like.

2. Documentations & Clear Interfaces

It’s no secret that knowledge is a key to quality and the ability to recreate and invent. Whoever did not have a toy as a child and cracked it up to see how it worked? To prevent developers from screwing up software they don’t fully grasp, it’s so necessary to equip them with a good structured piece of information about how the wheels turn and on the other hand to make them use it. I often realized writing functional backend code during a project, that had already been brought to me by another developer or even a framework or that did not match the ideals of the software itself. So I force myself to make an effort on asking documentations for their solutions before reinventing the wheel. Even if no habit on top down documentation is fostered in a team, there’s still the good custom to leave some precise comments on tricky passages in the source code itself.

3. Codechecks and IDEs

For a long time I’d been searching for the purpose of an IDE. Why? My company is special, because the people are. Everyone has it’s own criteria and preferences to suit. So I had been confronted with several religions, varying from i-know-what-you-wrote-last-summer-autocomplete-fanatics up to Vim-for-world-domination-zealots. What I’d been missing is the power of intelligence, that enriches me in developing solutions, speeds up their implementation, corrects my style- & programming-mistakes and leads me through the hundreds of annoying deployment workouts.

Since I enjoy an IDE (suggested by a wonderful colleague & mentor), that advises me to conventions and prevents me from running into syntax errors without slowing down my working process, my code quality raises. However, there are different approaches à la checkstyle for java which guard coding standards throughout your team without requiring a specific IDE.

4. Tests

There’s never time / money enough, nor the mood for good testing. But in fact it raises quality according to the effort being made. Approaches are as different as the errors, but they all have something in common: They just correct software but never tell how it should look like. Keep in mind that good testing needs good specifications (aka concepts).

Another neglected fact I wanted to mention is, that functional tests of a developer will never be a test for meeting the requirements of a business process. This will only be achieved by ordering non-developers with knowledge of the processes to the front row.

5. Brain

If everything fails, rely on brain =)