Easiness Duality

Background

Some time ago I started to write an article about an utopic world, where computer programs don't have bugs (at least not in production) and how we may achieve that.

I never really though that article was worth publishing, but the idea never left my mind, so I rethink the entire subject and what came to my mind is that easiness is the source of all evil. OK, not all, but most part of it.

So I decided to write about it. At least I think this article is going to be more focused than the other.

Pros and Cons of Easiness

Even if some arguments here may apply outside the programming and computer world, in this article I only plan to discuss the consequences of easiness to programs or, better, to programmers who end-up writing code.

So, let's first see the arguments that prove that easiness is a good think (which is the most natural thinking):

• Developers can focus on the real problem (usually, the business logic) instead of losing time with hard algorithms;
• Easier to read code means "anyone"(considering developers) reading it will understand it;
• Easier to write code means managers can finish their projects with smaller budgets, be it because they can hire less skilled developers or because there will be less bugs;
• Easier usually means faster and being the first on any domain usually gives an edge over the competition.

And, with all those good arguments, what can go wrong?

My initial answer is: A lot of things. Let's see some examples:

• With easiness comes lazyness. Good developers may produce more, but most developers will produce the same, simply because they will understand the bare minimum to do the work;
• Not everything becomes easier at the same proportion and so, developers that before were capable of solving hard problems and now only solve medium problems are no more capable of solving those hard problems that may still arise;
• As it's "easy" much more people will start to do it. In this case, many people that don't like programming and don't have any interest on it may be able to produce bad quality software and believe they are doing great. Later, they will spend (or the company that hired those persons will spend) much more money trying to "optimize" something that started wrong;
• The "easy and wrong" may become so famous that you, the good developer, may be forced to make things "as easy as that something else" even if you know all the problems that may come along.

Aren't you convinced?

Let's see an example: SQL Injection.

Today it is largely known that we should never concatenate strings directly to give parameters to the SQL. That is, instead of writing:

"SELECT SomeField FROM SomeTable WHERE SomeOtherField=" + stringVariableThatContainsAnUserValue

We should use a parameter placeholder. Something like:

"SELECT SomeField FROM SomeTable WHERE SomeOtherField=@SomeOtherField"

And then we fill that "@SomeOtherField" with an user value.

But, especially with old data access libraries (and this includes the ADO.NET) filling such parameters isn't easy. A command that could be executed with a single line (like a direct execute) becomes a multiple statement command that:

• Requires a command object to be created;
• Requires the command text to be filled (this is the SQL with those place holders);
• Requires the parameter objects (that "fill" the parameters) to be created or required to find them in some way;
• Requires to fill those parameters;
• Maybe requires to tell when those parameters are null and which type they should be;
• Executea the command;
• Maybe deletes/closes such command object.

Much harder, ins't it?

But, by doing the harder version we don't have any risk of SQL Injection. Any string that in normal concatenation causes an SQL injection will simply be passed to the parameter, maybe throwing an exception because it has an invalid value (a string value where an int is expected), maybe inserting a strange value in the database, but definetely will not suffer the attack of SQL Injection.

So, how much money could be saved if SQL Databases simply didn't accept direct values in SQL statements?

I am not questioning the order in which things happened (maybe writing values in SQL was the first way to do things, and later parameters were created to avoid parsing texts... I really don't know) yet such value parsing is still done in SQL databases (and it is expected to be that way) and it caused lots of losses simply because such "easy alternative" to parameter placeholders are there and many new developers (and even old but lazy ones) will use it, as it means writing less code and, in normal tests, it works.

Do you want more examples?

OK, I will probably look like a SQL hater now, but I will talk about SQL again. What do you think about things like:

• Cascade deletes?
• And update or deletes without the WHERE clause?
• And better yet, what about combining those with automatic commits?

If you are a SQL expert you probably consider anyone writing an update or delete without WHERE stupid, but that happens even to experienced developers and database administrators.

To complete that, some editors try to help us from losing time writing commit statements, doing them automatically. But, considering the problems that can be caused, does it worth it?

So, why not make those mandatory? If we really need to update or delete all records we could always use things like "WHERE ALL", "WHERE TRUE" or even strange but functional conditions like "WHERE 0=0".

OK. I don't expect such behavior to be corrected in SQL now (and that's why I initially though about an utopic world), but those are examples to think about.

Garbage Collection

I was criticizing SQL too much. So, what about Garbage Collection?

Personally I love it. It really simplifies programs by removing a lot of try/finally clauses to do the deletes and removes a lot of complexities, in special to circular references or objects added to lists that aren't under our control.

So, what can go wrong?

Remember the programmer's lazyness that I talked before? Well, it goes one step further and many new developers simply don't understand why managing memory is important.

If the problem was limited to new programmers, who eventually learned how to deal with memory that wouldn't be that bad, but even with garbage collection we should still take care of memory, be it by the use of Dispose() to free unmanaged resources immediately, be it by unregistering events (one of the hardest to spot bugs, because it usually don't affect applications when they are small, but becomes a problem in very busy servers) and the easiness of garbage collection created the illusion that developers shouldn't take care of memory at all.

To make things worse, I listened more than one .NET architect saying that we should never dispose objects, that the .NET should take care of memory, not us (apparently they read that we should not call GC.Collect() and understood that Dispose() is bad). But what impress me is that I heard such kind of affirmations in Brazil and in Canada (initially I though it was only a Brazilian problem, maybe related to some bad translation, but when I heard the same kind of "information" in Canada, being used as the development guideline and also hearing that having to Dispose() disposable objects is an unacceptable change to correct problems related to unfreed resources, well, I got speechless.

Even if you never heard such kind of affirmations, one thing that impress me is that when I started to program, knowing how to deal with pointers and how to free memory was one of the most basic concepts to be able to program computers. Today, it seems that talking about freeing memory or using a single pointer is a topic too advanced exclusively to crazy genious, as even "senior" developers don't know how to do it.

Is harder better?

Reading that easiness may be bad may give the impression that I am saying that the harder the code is, the better.

Well, I am not saying easy things are completely bad. I am only saying that it may bring problems.

If we only had assembler, I am pretty sure that large applications would be almost inexistent and many good developers would have simply avoided computers before even trying to use them. So, no, I am not saying being harder is better. I am also not saying that having easy things is bad. What I am saying is that too easy may bring bad consequences.

In fact, I can compare it with a game. When we play games we expect the first levels to be easy and then to have harder and harder levels. If all the levels were as hard as the last one, most people will simply abandon the game (but then we could see some crazy or very skilled players that will continue to play and have fun with it). So, in my opinion, programming languages and development tools should be seen the same way. After learning the "basic" (and I am not talking about the BASIC language) developers should not stop there and should at least understand the most advanced concepts, even if they continue to use the easier alternatives.

Also, when developing components and libraries, it is important to remember that some "easy calls" (like deletes without parameters, default method parameters and many code generators in general) may help at one moment and may cause much more problems than what they actually made easier.

Conclusion or "Why did I write this?"

I consider this as a text for reflection. I don't expect decade old solutions to simply change from day to night or that companies that develop those "easy solutions" that become a problem in the future to stop doing it.

But if you are in a position to decide, remember that when things are too easy quality is not really going to improve. Also, if the easier means it becomes easier to do bad things, it is better to have something a little harder or verbose and kill the problems before they start to bite you.