Odpowiedź: 42

Świat IT jest pełen odpowiedzi...

• Jak pisać czytelniej? Dzielić algorytmy i metody na mniejsze kawałki. Pisali o tym McConnell, Beck, Martin.
  
• Jak radzić sobie implementacją złożonego procesu? Można wydzielić współpracujące ze sobą obiekty. Pisał o tym Meyer.
  
• Jak okiełznać złożoność domenową? Można zastosować wyróżnić bounded contexts itd. Pisali o tym Evans, Vernon, Dahan, Young i inni.
  
• Jak dokładniej testować? Pisać mniejsze testy skupione na konkretnym zachowaniu. To, akurat mówią wszyscy...
  
• Jak poprawić trafność oszacowania? Można dekomponować na podzadania. Pisał o tym McConnell.
  
• Jak ogarnąć mega złożone interfejsy UI? Podzielić ma mniejsze lepiej zarządzalne kawałki i skomunikować między sobą. Zrobili np. w robotlegs framework.
  
• Jak skalować agility? Zacząć od skalowania produktu i podzielenia go na mniejsze podprodukty. Mówili o tym Poppendieckowie.
  
• Jak poprawić swoją efektywność. Skupić się na mniejszej ilości spraw. To tłuką na konferencjach bez litości.
  
• Jak uniknąć kosztownego refaktoringu i mądrzej ogarnąć architekturę? Wydzielić odpowiednio małe microserives. Mówił o tym Young.
  
• itd.
  

Wymienione odpowiedzi są pożyteczne, ale chyba gdzieś umknęło pytanie. Otóż podstawowym pytaniem, z którym boryka się uniwersum IT jest pytanie o granulację. Ile to jest mało, ile dużo, a ile odpowiednio?
Jaki serwis będzie OK, a jaki za duży? I w jakim stopniu zależy to od kontekstu?

Kłopot w tym, że żadne z wymienionych odpowiedzi, ani chyba też żadne, które znamy, nie adresuje tego podstawowego pytania.