When developing a system, it is very easy to cross a certain boundary – on the one hand we want to predict all possibilities and 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 the smallest changes. How to deal with “overdesign”? How, at the same time, not to close for improvement and changes? When should we make crucial technical decisions and when to accept technical debt? This talk is about true stories, mostly about huge mistakes, but also about decisions that in the end were very sucessfull. The talk is dedicated to all of those who don’t want to end up with a project that needs to be rewritten whenever we want to add a new button. The session is for all of those who care.
45. 1. Klient zawsze oczekuje jakości,
2. Jakość nie jest wartością 0:1,
46. 1. Klient zawsze oczekuje jakości,
2. Jakość nie jest wartością 0:1,
3. Podejmuj decyzje najpóźniej jak to możliwe,
47. 1. Klient zawsze oczekuje jakości,
2. Jakość nie jest wartością 0:1,
3. Podejmuj decyzje najpóźniej jak to możliwe,
4. Kod źródłowy testów nie jest mniej ważny od kodu produkcyjnego!
48. 1. Klient zawsze oczekuje jakości,
2. Jakość nie jest wartością 0:1,
3. Podejmuj decyzje najpóźniej jak to możliwe,
4. Kod źródłowy testów nie jest mniej ważny od kodu produkcyjnego!
5. Nigdy nie zapominaj o refaktoryzacji,
49. 1. Klient zawsze oczekuje jakości,
2. Jakość nie jest wartością 0:1,
3. Podejmuj decyzje najpóźniej jak to możliwe,
4. Kod źródłowy testów nie jest mniej ważny od kodu produkcyjnego!
5. Nigdy nie zapominaj o refaktoryzacji,
6. "Scrappy" zostanie na dłużej niż sądzisz,
50. 1. Klient zawsze oczekuje jakości,
2. Jakość nie jest wartością 0:1,
3. Podejmuj decyzje najpóźniej jak to możliwe,
4. Kod źródłowy testów nie jest mniej ważny od kodu produkcyjnego!
5. Nigdy nie zapominaj o refaktoryzacji,
6. "Scrappy" zostanie na dłużej niż sądzisz,
7. Pisz biblioteki, nie frameworki,
51. 1. Klient zawsze oczekuje jakości,
2. Jakość nie jest wartością 0:1,
3. Podejmuj decyzje najpóźniej jak to możliwe,
4. Kod źródłowy testów nie jest mniej ważny od kodu produkcyjnego!
5. Nigdy nie zapominaj o refaktoryzacji,
6. "Scrappy" zostanie na dłużej niż sądzisz,
7. Pisz biblioteki, nie frameworki,
8. Nie zamykaj się na nowe technologie, ale równocześnie ograniczaj ich ilość,
52. 1. Klient zawsze oczekuje jakości,
2. Jakość nie jest wartością 0:1,
3. Podejmuj decyzje najpóźniej jak to możliwe,
4. Kod źródłowy testów nie jest mniej ważny od kodu produkcyjnego!
5. Nigdy nie zapominaj o refaktoryzacji,
6. "Scrappy" zostanie na dłużej niż sądzisz,
7. Pisz biblioteki, nie frameworki,
8. Nie zamykaj się na nowe technologie, ale równocześnie ograniczaj ich ilość,
9. Staraj się równoważyć ilość testów pod względem ich kosztów utrzymania,
53. 1. Klient zawsze oczekuje jakości,
2. Jakość nie jest wartością 0:1,
3. Podejmuj decyzje najpóźniej jak to możliwe,
4. Kod źródłowy testów nie jest mniej ważny od kodu produkcyjnego!
5. Nigdy nie zapominaj o refaktoryzacji,
6. "Scrappy" zostanie na dłużej niż sądzisz,
7. Pisz biblioteki, nie frameworki,
8. Nie zamykaj się na nowe technologie, ale równocześnie ograniczaj ich ilość,
9. Staraj się równoważyć ilość testów pod względem ich kosztów utrzymania,
10. Korzystaj z testów automatycznych zgodnie z ich przeznaczeniem,
54. 1. Klient zawsze oczekuje jakości,
2. Jakość nie jest wartością 0:1,
3. Podejmuj decyzje najpóźniej jak to możliwe,
4. Kod źródłowy testów nie jest mniej ważny od kodu produkcyjnego!
5. Nigdy nie zapominaj o refaktoryzacji,
6. "Scrappy" zostanie na dłużej niż sądzisz,
7. Pisz biblioteki, nie frameworki,
8. Nie zamykaj się na nowe technologie, ale równocześnie ograniczaj ich ilość,
9. Staraj się równoważyć ilość testów pod względem ich kosztów utrzymania,
10. Korzystaj z testów automatycznych zgodnie z ich przeznaczeniem,
11. Nie traktuj testów jako odrębnego bytu.