During development phase its very easy to cross the design boundary - we want to take care about all possibilities and potential changes that can happen in our project. On the other hand when we are under the time pressure we take shortcuts which could in the end increase cost of even simple changes. How to deal with "overdesign"? How (at the same time) don't close for improvements and changes? When we should make crucial technical decisions and when accept technical debt? This session is about true stories, mostly about huge mistakes, but also sometimes about decisions which in the end were very sucessfull. The session for all who don't want to end up with project that need's to be rewritten to add a new button. The session for all who cares.

1. Evolving Architecture
@dpokusa

3. Document
A B C

4. Document
A B CDocumentFactory

5. Document
A B CDocumentFactory
AbstractDocumentFactory

6. Document
A B CDocumentFactory
AbstractDocumentFactory
SectionA SectionB

7. Document
A B CDocumentFactory
AbstractDocumentFactory
SectionA SectionB
Decorated
A

8. fot. Iza Janoszek, Radio Eska

9. Overdesign

10. DIE

11. DRYDIE

12. https://commons.wikimedia.org/wiki/File:Tecnology_Life_Cycle.png

15. UNDERDESIGN

16. KISS

17. YAGNIKISS

20. COMMONS

21. COMMONS
UTILS
BASE
GENERAL
STUFF
SHARED
POPULAR
VARY
GLOBAL

22. A
COMMONS
CA B

25. Quality means doing it right
when no one is looking
- Henry Ford

26. CZAS
FUNKCJONALNOŚĆ
ZASOBY

27. CZAS
FUNKCJONALNOŚĆ
ZASOBY

28. CZAS
FUNKCJONALNOŚĆ
ZASOBY

29. CZAS
FUNKCJONALNOŚĆ
ZASOBY

31. JAKOŚĆ
CZASFUNKCJONALNOŚĆ
ZASOBY

32. JAKOŚĆ
CZASFUNKCJONALNOŚĆ
ZASOBY

33. JAKOŚĆ
CZASFUNKCJONALNOŚĆ
ZASOBY

34. JAKOŚĆ
CZASFUNKCJONALNOŚĆ
ZASOBY

35. JAKOŚĆ
CZASFUNKCJONALNOŚĆ
ZASOBY

36. QUALITY

39. TECHNOLOGY FREEDOM

42. TECHNOLOGY PRISON

45. READABILITY CONSIDERATIONS

47. 1. Podejmuj decyzje najpóźniej jak to możliwe,

48. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,

49. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,

50. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,

51. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,

52. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,

53. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
7. "Scrappy" zostanie na dłużej niż sądzisz,

54. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
7. "Scrappy" zostanie na dłużej niż sądzisz,
8. Pisz biblioteki, nie frameworki,

55. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
7. "Scrappy" zostanie na dłużej niż sądzisz,
8. Pisz biblioteki, nie frameworki,
9. Spróbuj zrozumieć biznes,

56. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
7. "Scrappy" zostanie na dłużej niż sądzisz,
8. Pisz biblioteki, nie frameworki,
9. Spróbuj zrozumieć biznes,
10. Jeśli tylko możesz -> DDD i TDD,

57. 1. Podejmuj decyzje najpóźniej jak to możliwe,
2. Pierwszym rozwiązaniem zazwyczaj nie jest wzorzec projektowy,
3. Klient zawsze oczekuje jakości,
4. Kod powinien być czytelny,
5. Nigdy nie zapominaj o refaktoryzacji,
6. Nie traktuj testów jako odrębnego bytu,
7. "Scrappy" zostanie na dłużej niż sądzisz,
8. Pisz biblioteki, nie frameworki,
9. Spróbuj zrozumieć domenę biznesową,
10. Jeśli tylko możesz -> DDD i TDD,
11. Nie zamykaj się na nowe technologie, ale równocześnie ograniczaj ich ilość.

58. ABOUT
software-empathy.pl
@dpokusa

59. @dpokusa
ABOUT
SPREADIT.PL
18.11.2017

60. @dpokusa
ABOUT

61. Q&A