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 successful. 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

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

12. UNDERDESIGN

15. COMMONS

16. COMMONS
UTILS
BASE
GENERAL
STUFF
SHARED
POPULAR
VARY
GLOBAL

17. A
COMMONS
CA B

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

20. CZAS
FUNKCJONALNOŚĆ
ZASOBY

21. QUALITY

22. JAKOŚĆ
CZASFUNKCJONALNOŚĆ
ZASOBY

23. JAKOŚĆ
CZASFUNKCJONALNOŚĆ
ZASOBY

24. JAKOŚĆ
CZASFUNKCJONALNOŚĆ
ZASOBY

25. JAKOŚĆ
CZASFUNKCJONALNOŚĆ
ZASOBY

29. TECHNOLOGY FREEDOM

32. TECHNOLOGY PRISON

35. READABILITY CONSIDERATIONS

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

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

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

40. 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,

41. 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,

42. 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,

43. 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,

44. 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,

45. 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,

46. 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,

47. 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,
11. Nie zamykaj się na nowe technologie, ale równocześnie ograniczaj ich ilość.

48. ABOUT
software-empathy.pl
@dpokusa
Danielpokusa.pl

49. @dpokusa
ABOUT
SPREADIT.PL

50. Q&A