AE Stories

You work six months on your ‘perfect’ site. You spend a lot of money on good designers, make it look nice on a smartphone. And then the big day comes, houston, we have liftoff! For it is just after three months later that you realize your site just sits there in a corner wheepin’ because google won’t put it on number one. I too learned it the hard way, and went on a secret mission to make my site score better in Google. Here are 7 quick-wins I’ve encountered on my mission to take over the world (with my tiny fancy site)…

Why should you be making this distinction?

If you are not making it, you probably recognize some of these issues:

• you are redescribing your product over and over again for every new project
• there is no documentation of your product as a whole, in stead pieces are described depending on what was relevant for the project
• It is hard to find existing documentation as it is organized per project in stead of per product

You might be a developer like me. You might also wander around in the deep and dark layers of relational database systems. You might've been face to face with this thing some call a composite index.

Why are you talking in this denigrating tone?

Because in the fairly limited experience I have, I have seen some grave cases of index abuse. Of them, badly designed composite indexes - or multi-column indexes - were always the most aggravating ones.

There is a question that often returns: How do we know which analysis techniques we need to apply? There are of course several considerations to be made.

You can for example consider the nature of the system or the composition of the team. One good place to start is to take a look at the stakeholders of your analysis. Whom are you making it for?

Despite agile and lean being more popular than ever, 200 page analysis documents are still very much a reality. There are many reasons why you shouldn’t write this type of documentation but if I would have to choose one major reason it is that nobody actually likes to read these documents. Here are some other good reasons not to.

Inconsistencies

It is hard for anyone to remain consistent throughout a long plain text. Inconsistencies already start creeping in while you’re working on the first version. Then updates are made by you or even more risky, by other people. (If you don’t believe me, just take a look at all the inconsistencies in the Harry Potter series.)