modulair cloud

Why is there no modulair cloud?

What I mean is, why are there only complex infrastructures, or full blown enterprise applications available as Saas? As a small business I don't want to pay for those extreme systems (which I don't need), but I would like to take advantage of the possibilities of cloud computing.

Sure, Google Apps is a great place to start. It brings me office applications, communication (like mail, chat etc) and some other nice stuff and all that for free (or even more for a small fee). But if I want to go beyond that, I have a problem.

Let's say I would like to have some sort of lightweight CRM system. I only want to store contact information and share that across my company. I don't need the option to connect tasks, documents, opportunities and stuff like that. Google Apps doesn't give me that and most other providers give me (and charge me for) way too much!
Another example: I only want some system that can register the hours I and colleagues spend on a specific project, but without all the fancy project management features like planning, collaboration and so on.
What I would like to have is some kind of Saas á la carte, where I can combine separate modules into a complete, tailored back office system that gives me exactly what I need and nothing more.

As far as I know there is nothing like that yet on the market. If there is, please let me know!

stick to your language

Very often I see code fragments where programmers try to be smart. Don't!

Obviously there is nothing against being smart, but don't try to be smarter than necessary.

Most of the time these smart tricks have to do with compiler optimizations.

An example:

Imagine you have a method doSomething() that only has to be performed if another method checkAndDoSomething() returns true. That method in its turn only has to be performed if switch boolDoIt is set to true. Some programmers like to take advantage of the fact that most compilers optimize the code so, that in an and operation if the first element evaluates to false, the second element isn't evaluated at all and write code like this:

if (boolDoIt and checkAndDoSomething()) {
 doSomething();
}

If you can rely on that optimization, you know that if boolDoIt evaluates to false, the checkAndDoSomething() method isn't performed, and neither will doSomething().

But what if the compiler vendor decides to drop that optimization for some reason? Then all of a sudden both elements are evaluated, so the method checkAndDoSomething() will be performed no matter the value of boolDoIt! Completely changing the behaviour of your code and violating the meaning of the switch.

A better, more stable way, would be:

if (boolDoIt) {
 if (checkAndDoSomething()) {
   doSomething();
 }
}

I know, this looks like kindergarten code and is not fancy. But the code is easy to read and compiler independent. And probably after optimization by the compiler exactly the same ;-)

In other words:
write your code and functionality using the specifications of your programming language, not of your compiler.

KISBNS

Keep It Simple, But Not Stupid!

The idioms KISS (Keep It Simple, Stupid!) and KISSALAP (Keep It Simple, Stupid, As Long As Possible) are great methods to get your code up fast and keep it stable. Surely writing code for something you'll probably never use can only make thing unnecessary complicated and therefore unstable and unmaintainable.

BUT:
I often see pieces of code where people tried to keep those principles, but forgot to refactor in time until it's too late. What I mean is, people tend to start copying pieces of code, thinking 'making this piece of code more generic while I would only use it twice is not simple enough.' Maybe that's true. But then they copy it a third time, or code it again because they forgot it allready existed somewhere.
In these cases making a generic method, class or whatever the first time would have been a better idea.

So as soon as a piece of code is obvious to reoccur several times, extract it immediately before it's too late!

scalable architecture

Very often when I join a project, I see developers performing all kinds of tricks just to stay within their architecture.

Sure, it is a good idea do determine or develop some kind of architecture when you start a project. If you don't do that after a while your software won't be readable or maintainable anymore. Developers will come and go, each bringing in their own style of doing things. But if your system evolves, it's very likely that your working architecture will not live up to its needs. Therefore don't hesitate to adjust your architecture instead of wasting time and money trying to figure out hacks to solve the problem within the current standards.

In other words: ''Scale your Architecture''

name functional

When naming objects (being it classes, methods or whatever) let the name describe what it is or does, NOT HOW!

An example:
I recently worked on a database where a column was defined by a user defined type. The naming convention used stated that the name should contain the base type used in the udt. In this case it was a tinyint, so the name of the type started with udti_. I had to change the column to a smallint because the original tinyint just couldn't cope with all the different values anymore. Normally one of the biggest advantages of user defined types is that you only have to change the type definition and you're done. In this case I had to create a new udt (just because the name had to change to udsi_) and redefine all tables, stored procedures, functions and triggers that used or referred to the original type.

Describing the inner workings of an object in it's name limits the flexibility in future development and also breaks the encapsulation rules.

Who am I?

First of all, see my profile on Linked-In:

Now that you have at least some idea who I am, I'd like to share with you my reason for starting this blog. There's nothing new about it. Just some thoughts about software development and curious stuff I've encountered while doing my work