Marek Kubiś

Marek Kubiś programista c#

Temat: Szybko, szybciej i brutalna prawda reguły Pareto

Jakiś czas temu znów miałem powód do myślenia, czy pisanie kodu programu powoli jest równoznaczne nie na czas. A jeśli kod ma powstać na czas to co to oznacza w praktyce.

więcej
Paweł Lubczyński

Paweł Lubczyński interesuje mnie
praca zdalna

Temat: Szybko, szybciej i brutalna prawda reguły Pareto

dziwna teza... i dziwne końcowe pytanie . Wg. mojej opinii wszystko powinno mieć ramy czasowe ... Ponadto co ma do tego pareto? przeciez rozkład 0,2 / 0,8 jest tylko strike umowny
Marek Kubiś

Marek Kubiś programista c#

Temat: Szybko, szybciej i brutalna prawda reguły Pareto

Paweł L.:
dziwna teza... i dziwne końcowe pytanie .
??? Chodzi o wolno == nie na czas ? Przecież wielu tak właśnie utożsamia te dwie sprawy. Gdyby tak nie było to tego poganiania w życiu codziennym byłoby chyba mniej? Nieprawdaż?
Wg. mojej opinii wszystko powinno mieć ramy czasowe ...
Wszystko, czyli i część i całość. OK, ale przecież schodzenie do zbyt uszczegółowionych warunków nie ma sensu i nie praktykuje się tego. Praktykuje się natomiast ustalanie ram czasowych dla jakichś większych fragmentów, moduł, logicznie spójny fragment całości. Ale na koniec trzeba to wszystko scalić i tutaj zaczynają się problemy, które potrafią zaburzyć nie jeden grafik.
Ponadto co ma do tego pareto? przeciez rozkład 0,2 / 0,8 jest tylko strike umowny
Umowny? Nie mam nic przeciwko traktowaniu Pareto jako rozkładu przybliżonego, bo przecież czy będzie to 22% / 78% czy 15% / 85% lub tp., to nie ma to co do zasady większego znaczenia. Ale Pareto to reguła powstała na podstawie obserwacji rzeczywistości. Tak po prostu okazuje się, że tak toczy się wiele spraw, tak dzieje się wiele rzeczy i już. Nie ma tu miejsca na umawianie się, bo chodzi o końcową ocenę po zamknięciu tematu.
Paweł Lubczyński

Paweł Lubczyński interesuje mnie
praca zdalna

Temat: Szybko, szybciej i brutalna prawda reguły Pareto

Marek K.:
Paweł L.:
dziwna teza... i dziwne końcowe pytanie .
??? Chodzi o wolno == nie na czas ? Przecież wielu tak właśnie utożsamia te dwie sprawy. Gdyby tak nie było to tego poganiania w życiu codziennym byłoby chyba mniej? Nieprawdaż?
Wg. mojej opinii wszystko powinno mieć ramy czasowe ...
Wszystko, czyli i część i całość. OK, ale przecież schodzenie do zbyt uszczegółowionych warunków nie ma sensu i nie praktykuje się tego. Praktykuje się natomiast ustalanie ram czasowych dla jakichś większych fragmentów, moduł, logicznie spójny fragment całości. Ale na koniec trzeba to wszystko scalić i tutaj zaczynają się problemy, które potrafią zaburzyć nie jeden grafik.
Ponadto co ma do tego pareto? przeciez rozkład 0,2 / 0,8 jest tylko strike umowny
Umowny? Nie mam nic przeciwko traktowaniu Pareto jako rozkładu przybliżonego, bo przecież czy będzie to 22% / 78% czy 15% / 85% lub tp., to nie ma to co do zasady większego znaczenia. Ale Pareto to reguła powstała na podstawie obserwacji rzeczywistości. Tak po prostu okazuje się, że tak toczy się wiele spraw, tak dzieje się wiele rzeczy i już. Nie ma tu miejsca na umawianie się, bo chodzi o końcową ocenę po zamknięciu tematu.

Jaki sens ma twój wywód? Quo vadis, Domine?
Marek Kubiś

Marek Kubiś programista c#

Temat: Szybko, szybciej i brutalna prawda reguły Pareto

Paweł L.:
Jaki sens ma twój wywód? Quo vadis, Domine?
Nie wszystko co jest proste jest zrozumiałe.
Paweł Lubczyński

Paweł Lubczyński interesuje mnie
praca zdalna

Temat: Szybko, szybciej i brutalna prawda reguły Pareto

ta dyskusją nic nie wnosi :-) takie chrzanienie o d...
ide sie zastanowic czy jezeli herbata bedzie mi sie parzyć wolno to czy to będzie na czas
miłego śniadania :)
Marek Kubiś

Marek Kubiś programista c#

Temat: Szybko, szybciej i brutalna prawda reguły Pareto

Paweł L.:
takie chrzanienie o d...
ide sie zastanowic czy jezeli herbata bedzie mi sie parzyć wolno to czy to będzie na czas
Obśmiać można wszystko. :-( Każdy niech się zastanawia nad tym co uzna za warte poświęcania jego czasu.

Ja ze swojej strony zadałem sobie jedynie pytanie, czy jeżeli jakiś fragment kodu można napisać np: w 1 godzinę, to ile warto dołożyć do tego czasu aby dołożyć coś ekstra, coś co później kiedy będzie się uruchamiać całość na koniec dało korzyść w postaci skrócenia, a nie wydłużenia czasu realizacji przedsięwzięcia.

Nie da się ukryć, że istnieje granica pomiędzy tym co warto, a czego nie warto robić dodatkowo. W szczegółach wszystko zależy od konkretnego kawałka kodu, ale widać też zależność w skali makro, w szczególności na poziomie zarządzania projektem, zarządzania zespołem. To wbrew pozorom istotne na jakie opóźnienia warto się godzić, a na jakie absolutnie nie warto. No ale przede wszystkim to trzeba mieć także potrzebę takiego zastanawiania się, bo w każdej innej sytuacji to takie chrzanienie.

Podobne tematy


Następna dyskusja:

Dobrze i szybko programować




Wyślij zaproszenie do