Ten Signs of an Unprofessional Application (or How to Lose a Client)

This summer I was asked to assess a simple online store to estimate the cost and effort required to add new features (and fix a few things that weren’t working properly). To my surprise, I found something common in our industry: applications that are poorly conceived, badly made, and written any old way, even though the end client had generated more than twenty thousand euros in orders through it over the past year.

Here’s an example I often bring up: when we buy a car, we care about many of its features and performance—and, of course, details of its inner workings (who made the engine, and so on). Similarly, building a house requires the signature of a licensed architect (at least in Spain), whose role is supposedly to oversee all the technical aspects of construction.

So I wonder why, when it comes to a software project, almost no client thinks to ask about or care about the quality of what they’re being given. They may not realize that quality determines whether evolving or improving the application in the future will be affordable and reasonable—or prohibitively expensive (if the system doesn’t end up being thrown away and rebuilt from scratch).

In our profession, clients of all sizes—from small businesses to medium-sized companies and large corporations—are very often handed applications that are really a poisoned apple, destined to blow up later as soon as the client needs modifications or changes, as happens with almost any kind of software.

Would we buy a car that can’t be repaired or maintained? Absurd.

This raises several questions for me. How do we demonstrate the quality of the software we deliver to a client?

How do we stand out from the competition and assure clients that our solution will be easier to maintain as it changes? This is a big subject and one of those recurring issues we encounter day in and day out.

Would a client be willing to pay more if we guaranteed better internal quality in what we offer? Would independent quality audits make sense, so that a product could be declared complete with an accredited software-quality certificate? All right, I know such audits exist and are used on large projects for major companies, but that’s a drop in the ocean.

In the case I mentioned at the beginning, one quick look at the application’s structure made me fear the worst…

Here’s a brief description of what stood out most:

1. No documentation. By no documentation, I mean not even a simple comment in any source file, let alone a document explaining the design guidelines followed. All we can do is dig around in the application and try to figure out—or guess—how it’s organized. There was no deployment guide either to offer any clues about setting up the application in a development or production environment.
2. No sign of any tests. I’d say this is the worst part, because manually testing everything takes dramatically longer, and when you change something, you have no assurance that you’re not breaking anything (does this really need explaining?).
3. No database design. All that existed was a very long script exported from phpMyAdmin…
4. No evidence of version control. This isn’t absolutely essential in itself when taking over an application, but the fact that no version-control tool was used gives you an idea of how the application was built in the first place.
5. The same passwords configured in multiple places. Having hard-coded passwords scattered around isn’t just bad; it’s a sign of a complete novice, unfortunately. Do I need to point out that if you have the same passwords or settings in X places, changing them means wasting a lot of time updating every single one (unless you forget one and then spend even longer debugging)?
6. Poor solution structure. By poor, I mean you couldn’t tell where the user interface was, where the back-end was, or even where the business logic might be. Everything was mixed together and scattered here and there. If it’s our first time using those technologies, it’s normal to feel a little lost about how best to organize things. Still, a quick GitHub search for boilerplate will turn up starter templates for all kinds of projects.
7. A buggy, homemade user-interface layout. This isn’t inherently wrong, but in a multi-browser world with many versions of each browser, building this kind of thing yourself can take a very long time if you want to ensure the layout works in at least the most commonly used browsers. Wouldn’t it be better to use something like 960 Grid System or one of the many mature solutions to this problem?
8. Large CSS and JS files that aren’t minified or concatenated. This isn’t essential either, but tools exist to reduce all the CSS and JavaScript files to a single .css and .js file (with the latter also obfuscated). Why not use them? Among other benefits, the application will load a little faster with each request.
9. Security holes, such as unencrypted database passwords and text fields whose content isn’t filtered to prevent XSS attacks. No comment.
10. Unused parts of the application. This isn’t necessarily wrong either, but if we keep dead code and unused parts around, the application becomes harder to organize and maintain. Only code the application actually uses should remain. If we’re afraid of losing it, why do we have version control?

That’s just the tip of the iceberg. I could also mention that the application wasn’t modularized or organized at all (data-access classes scattered around, front-end mixed with back-end), that there was no consistent coding style (private variables written in different ways, for example), and much more.

Criticizing is the last thing I want to do (I don’t want to rack up bad karma…), but I wonder how much it degrades our profession to deliver work like this, which then goes into production for a client whose revenue partly depends on the system.

I don’t know if this advice applies to everyone, but when I deliver a new piece of work, I try to assure the client that we’ve put a great deal of effort into making the quality of what we’re delivering high, in addition to meeting all the functional requirements correctly. Whether the client values that internal quality is another matter.