The best parts of development in a coding project is when you don't know what you want to do, and once you decide, you simply implement. The worst parts, project wise, are the parts when you know exactly what you want to do, but do not know how to do it. The reason for not knowing is usually due to abstractions inside the frameworks and libraries you are using. These are the real risks which can take a lot of time the first time they are encountered and get solved right away the next times. These are the issues which make deterministic project effort requirements almost impossible. A good name for such things might be "Semantic Black Holes".
We are faced with a lot in Soshiant.
Of course it is possible to reach deep inside these black holes and find out everything about how things are done and need to be done but the only thing lost during this process is the single crucial parameter usually represented using the "t" symbol.
On the other end the same frameworks speed up and help out in many tasks and provide lots of useful features which if you wanted to start and implement yourself it would have needed lots of time too.
Time saved for needed features which exist in a library and can be used: t1
Time spent to find out how the library can tweak to provide the exact need that you have: t2
Happiness = t1 - t2
We are faced with a lot in Soshiant.
Of course it is possible to reach deep inside these black holes and find out everything about how things are done and need to be done but the only thing lost during this process is the single crucial parameter usually represented using the "t" symbol.
On the other end the same frameworks speed up and help out in many tasks and provide lots of useful features which if you wanted to start and implement yourself it would have needed lots of time too.
Time saved for needed features which exist in a library and can be used: t1
Time spent to find out how the library can tweak to provide the exact need that you have: t2
Happiness = t1 - t2
No comments:
Post a Comment