Aglehg's Blog


Just another site

End day

I once read somewhere that a programmer is machine that transforms coffee in code… and eventually I fought in the company where I’m working to do just that… – I need focus on finishing that damn graduation… – I though

result => waste a lot more time codding because I’m totally out of the design.. so I have to work twice as hard to understand it… and deal with the fact that often I disagree with it, in a : as much passive way as possible… which is not much good for my stomach. It’s the trouble of being a girl I guess.. I get emotionally attached to the projects.  Like if each one of them was a child I wanted to see grow healthily..

Really.. I hate this pressure of “start coding” “start coding”.  Years of documentation on the importance of design… From my current knowledge…  mostly read, preached and applied in universities. Occasionally used in companies with university related people…   And pretended to be true else where.

Lesson learned: the more levels you have between the people that are implementing the request, and the person requesting.. the further away from it is the result. Do you know that game… tell a tale, to someone that tells the tale.. that tells the tale… make it circle around a table..

So far the best method, which I have only been able to apply for small free lance projects I did on the side. Seems to be a sort of “Iterative” development.

1º Request Requisites

2º Reply Interpretation of requisites with sketch design, as little implementation details as possible

3º Confirmation from client, with notes. Usually there are always corners that are bent.

4º Implementation of requisites

5º Submit to client evaluation. (you can call this the alfa )

6º Client inputs back changes  Repeat steps 4,5,6 until everyone is happy

It is more important to understand the problem, than to figure out ways of solving it. ‘Cause most of the time, you end up solving the wrong problem. To try to know everything from the beginning is just.. plain stupid. But you need to be very careful not to do the opposite. Which is why I like that feedback method. It’s not a conversation. It is an independent swap of readings of the problem. No one is in the way of anyones reasoning. So the odds of escaping comprehension are smaller.

I guess there’s a reason why big company’s use SRS’s… 

2.4 General Constraints

well it was done,  generally…




Filed under: e-moções, webdev

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da

Está a comentar usando a sua conta Terminar Sessão /  Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

Connecting to %s

%d bloggers like this: