Scrum, Kanban, XP, Scrumban, SAFe, Nexus, LeSS, DAD, Evo

There were days in the Java world when we were framework enthusiasts. Every single day new framework was deployed to sourceforge, googlecode, github, bitbucket or so on.

So it was turned out that being a Framework-Junkie led you to really poor architecture (see these articles: * Driven * do not change anything, Extremely Pragmatic Software Architecture, Measuring Software Architecture, Frame-of-our-work, What Exactly Are Patterns?).

Having this technological discussion out of our heads we started new one: what is the best agile framework. Yep, we are quite poor learners. How it possible that people who are trained to see repeatable patterns in the world don't see that we replay the old movie? - searching for the Silver Bullet.

Teams or whole organizations jump from one agile framework to another one - in the same way they jumped from Struts2 to JSF, from JSF to Spring MVC, etc. But they don't achieve desired effects.

If you wonder how to jump from SAFe to LeSS or another, or maybe you wonder which agile framework to use - I know the answer. Are you ready? - IT DOES NOT MATTER.

That's right - an agile framework doesn't do the job - PEOPLE DO. Don't try to bypass teams members skills by a new framework. This is a cognitive bias I described here.

Any framework was developed by highly-skilled professionals as a generalization of their daily routine. Having highly skilled people you will apply any framework, but a framework won't make your people better.

Again, frameworks are useful, but people and their skills are the key success factor.

It's Not Pround To Be Geek

Although 'Geek' defines some identity for a developer, being geek doesn't sound proundly for me. One having accepted this identity delimits oneself at the same time.

When you think you are Geek also create responsibility related to being Geek. Then it is easy to say: I am Geek, expecting an excellent requirements to start working or I don't wanna talk to stakeholders, this analyst's job, I am Geek or something else.

I've seen many IT-related conferences speeches. My observation is lots of speakers builds their authority around of being Geek. They leverage IT-business cooperation problems, present business-IT relationships with distorting mirror and think it's funny. Well, that is funny for geeks, but not for agilist.

Differentiating from 'Others' is a very powerful strategy for a speaker or for an individual in general. This strategy underlines what a group of individuals have in common and how they differ from 'Others' (read: business), helps to feel more self-confident. But this strategy doesn't help to be more open to a relationship with 'Others'.

So don't be Geek, but Agilist :)

The 'e' Letter Problem

I was inspired by Crista Lopes and her presentation to write this post. However, I found an analogy between her thoughts and my job, I recommend watching this presentation.

So, would you try to write a book or at least blog post without using words with the 'e' letter in the middle of a word? (In Polish it would be probably the 'a' letter). What implications it would cause? Would it be a challenge to express yourself giving the 'e' letter a miss?

Well, I think some of expectations about software development methodologies or techniques are similar to the 'e' letter restriction I mentioned:

• How to estimate this requirement? But I only have three-words explanation and that's all?
• How to start writing a code? But requirements will be precised soon ('soon' becomes 'now' when we will decide it is 'now')
• How to refactor 10-years old code during a weekend?
• How to deliver a software in 50% of time estimated with 50% of developers needed?
• How to start *DD with a team not experienced enough?
• How to accomplish more projects than our current capacity?
• How to motivate people with a pay cutting at the same time?
• How to boost our effectiveness without changing anything?
• etc.

There is no magic in the world. All methodologies and techniques have its own preconditions. These must be guaranteed before start. But we do repeat the same mistake over and over again. We want to write a book without the 'e' letter.

Software delivery organisational anti-patterns

It's good to have some electrical engineering background before reading this post ;P

I am confused every time I am asked what is the best way to manage requirements or which one is better: use cases or user stories, or how to ensure software quality by testing or how to evolve architecture properly, or does the *DD works, which design patterns are most wanted, what is better: agile or RUP. These are tricky questions, especially asked a consultant as I am.

Let's me try to explain what is a tricky part in these questions.

From IT point of view, the only goal of IT-Business collaboration is software delivery and nothing more. I like this term "software delivery" because it simply explains what we are responsible for. To achieve this goal we developed many tools which makes our work more effective. These tools address some difficulties we faced with when we collaborate with business people.


It is very important to notice these tools (show on the figure above) are not either-or dilemmas. You take whatever works and fits to a project context. Please read carefully at least:

• Writing Effective Use Cases by Alistair Cockburn
• Introducing BDD by Dan North
• Decisions, decisions by Dan North
• Specification By Example by Gojko Adzic
• Domain Driven Design by Eric Evans
• The Object Primer or agilemodeling.com by Scott Ambler

and you will see the tools are not competitors. Use stories are not compete with use cases, TDD is not competes with test-last approach, Scrum is not competes with free-style processes, DDD is not competes with simple anemic model, testing is not competes with test-free approach (really).

There is no "better", there is no "the best". Every single tools covers some aspect of IT-Business collaboration on software delivery. And everyone causes some benefits and consequences. But, you are responsible to choose a tool according to the project context. So yes, you should familiarize yourself with all of them.

The Source of All Evil

Problems start when one want to build a business around software delivery.

To scale the business one have to scale software delivery process to be more efficient.
So, one takes some of the tools and tries to compose The Process, for example: Analysis -> Architecting -> Implementing -> Testing -> Maintaining. So, tools becomes The Process steps and one builds teams around this steps.

You may say: ok it's old-school waterfall process. But, even organisations declaring agile approach have at least Analysis and Testing Departments. The rule is: the larger organisation is the more presented solution is applied. Where is a trick?

Software delivery is atomic. The only responsibility is to deliver software that is satisfying business needs and that's all. But scaling a software delivery we split this atomic thing into steps in a sequence.

We assume we may also split the Responsibility into small responsibilities of every single step. Moreover, we assume that Responsibility of whole software delivery is the superposition of the small responsibilities. In general it is not true.

You know, organisations where software is developed by programmers and tested by testers I may observe a lot of problems with a code quality and tension between Software Development Software Quality Departaments. Why? Because software developers are focused on their own responsibility and testers are focused on their own one.

Software Developers assume that testers will find all bugs and they are less motivated to test their own code. As a result tester have more and more work with bugs. And this a vicious circle.

One more example. Organisations where analysis is done by analysts (God, I'm trembling ever time I hear "Project Management Center") and development is done by developers, mostly have problems with requirements quality. It is happen that people don't know how to implement a requirement.

I think that problems listed above were caused by splitting what is unsplittable by the definition. Software delivery is unsplittable, it is atomic. We may use all tools to deliver better, faster or simpler. But we cannot split that tools into steps in a sequence. It doesn't work in that way. Once again: problems were not caused by the people or lack of competences. Problems were caused by the organisational anti-pattern.

Decoupled teams

Better idea is using tools around software delivery without splitting them.

Do you see the difference? Regardless of tools used the responsibility stays constant.
Ok, that was a metaphor but what about real world solution.

Solution is many stable Development Teams. A Team is responsible for delivering a complete working product. Moreover, there is no any dependencies between teams. A team is atomic.

Yes, I know there is more question than answers. How large a product should be? How to cooperate with other teams? How to build and develop a team? And so on, and so on.

The truth is we are in alpha-phase if about scaling agile teams on large projects and organisations. Some inspiration you may find in Disciplined Agile Delivery by Scott Ambler. Absolutely great case study is Scaling Agile @ Spotify. I believe the answer is out there and it will come soon.

UniversalProblemSolver

Jeżeli Twój kod przypomina coś takiego w/w, to pamiętaj, że wkrótce skończy Ci się paliwo i możesz już na zawsze pozostać na orbicie okołoprojektowej ;)

Na początek możesz przeczytać artykuł Zawsze pracuj na twardych danych.

Koder kodzi, architekt architekci

Na 4Developers odbył się Panel dyskusyjny nt. architektury, architektów i architekcenia:). Trudno powiedzieć, żebyśmy udzielili odpowiedzi na jakieś konkretne pytania, ale było miło. Chociaż padało pytanie o rolę/stanowisko architekta i jego miejsce w procesie, to wydaje mi się, że byłem odosobniony w zdaniu, że bez tradycyjnego architekta można się obejść. Podłapałem tę myśl od Scotta Amblera i po moich doświadczeniach z różnymi zespołami jestem przekonany, że to ma sens.

Ankietowałem kiedyś obsesyjnie, architektów (różne stanowiska różnie się się w firmach nazywają i mimo istniejących jakichś tam typologii, każdy nazywa je sobie po swojemu), aby namierzyć, co konkretnie robi osoba określana jako "architekt". Zbiorcze zestawienie przedstawiam poniżej.

Jaki jest Twój zakres obowiązków jako Architekta?

Odpowiadanie na pytania dotyczące struktury systemu Definiowanie interfejsów do/z systemów powiązanych Decydowanie o wykorzystywanej technologii na poziomie systemu Projektowanie deploymentu systemu Decydowanie o organizacji i rozmieszczeniu komponentów? Który kod umieszczany jest w bibliotekach, programach, gdzie są zewnętrzne biblioteki, co jest ładowane statycznie co dynamicznie? Utrzymywanie dokumentacji dotyczącej architektury system Zdefiniowanie struktury dokumentacji Określenie, które domeny biorą udział w danej funkcjonalności (co zapisują, co trzeba odczytać), jakie nowe interfejsy trzeba udostępnić, a jakie zmienić Prowadzenie prac R&D

Z jakimi pytaniami należy zwracać się do Architekta?

Ja ma odbywać się interakcja pomiędzy modułami/częściami systemu? Jakiej technologii najlepiej jest użyć do dostępu do bazy danych? Jak zabezpieczać pliki konfiguracyjne w systemie/aplikacji? Jaki model konfiguracji serwerów (np. Tomcat) przyjąć dla produktów/aplikacji webowych? Jak należy definiować zewnętrzne interfejsy systemu? Jakie elementy systemu i według jakich kryteriów mają podlegać walidacji? Jakie są główne komponenty systemu? Czy wymiana danej technologii mogłaby wspomóc działanie systemu? Jakich zmian wymagać będzie wprowadzenie danej funkcjonalności? Jak wygląda flow w danym komponencie (np. przetworzenie wiadomości w kolejce)? Jakie są wymagania funkcjonalne dla danego produktu Jak konkretny proces biznesowy realizowany jest w architekturze? Jak wygląda zużycie zasobów sprzętowych i programowych w danym okresie czasu? Jakie narzędzia i skrypty należy wdrożyć, aby usprawnić proces wytwarzania oprogramowania? Jak zorganizowana jest infrastruktura sprzętowa (jakie hosty? jak są powiązane?) i programowa (jakie wersje? gdzie?) systemu?

Z jakimi pytaniami NIE należy zwracać się do architekta?

Czy ta funkcjonalność działa poprawnie? Jakie projekty idą na najbliższy realese? Jaki będzie koszt projektu X? Jak działa ta funkcjonalność? Jak z korzystać z tego pakietu/biblioteki? Do jakich zadań planowany jest Pan X? Kiedy wypada deadline testów systemowych Jaki algorytm wykorzystać do…? Czy następujące zachowanie systemu jest poprawne?

Jeśli popatrzeć na wymienione obowiązki, to trudno oprzeć się wrażeniu, że z niemal wszystkimi z nich może sobie poradzić zespół jako taki i nie potrzeba do tego wydzielonego architekta. Jedyna różnica między w/w architektem a "zwykłym" programistą jest taka, że ma on architekt większe doświadczenie (ale nie to mierzone w latach) i większą wiedzę o systemie.

Wydaje się, że potrzeba powołania osoby w randze architekta wynika z potrzeby rozwiązania następujących problemów:

• niedostateczne komunikowanie architektury w zespole i pomiędzy zespołami
• brak nazwanego procesu rozwoju architektury działającego obok procesu dostarczania; o tym procesie pisaliśmy/mówiliśmy w Ewolucyjna architektura: Jak zorganizować proces rozwoju architektury?
, Ewolucyjna architektura, Ewolucyjna architektura
• Brak użytecznej (nie wciąganej z kodu przez EA) dokumentacji architektury; o tym pisaliśmy nieco w Dokumentowanie architektury, Dokumentowanie architektury cz.2

Można odnosić wrażenie, że tego typu architekt został wymyślony po to, aby wyousourcować w/w problemy. Sęk w tym, że staje się on wąskim gardłem procesu. Po prostu nie nadąża z pracą. Wtedy trzeba powołać kolejnego i kolejnego i kolejnego. Po pewnym czasie okazuje się, że architekci zajmują się głównie sprawami organizacyjno-konfiguracyjno-spotkaniowymi, a programiści przestają czuć się odpowiedzialni za architekturę, gdyż ta "należy" do architektów. I wtedy koder zaczyna kodzić, architekt zaczyna architekcić, a architektura zaczyna dryfować.

Dogmat architektoniczny, czyli nie wkurzaj programistów

W pewnej organizacji, człowiek o na stanowisku Architekt Korporacyjny zrobił zebranie, na którym objaśnił nową wizję architektury, nazywając ją dogmatem architektonicznym.
Programiści odwdzięczyli mu się zamieszczonym zdjęciem oraz drobiazgową analizą pojęcia dogmat architektoniczny, którą za pozwoleniem cytuję w całości.

Dogmat (z greckiego dogma - mniemanie, osąd, postanowienie, nauka),

1. W starożytności postanowienie prawne zgromadzenia ludu lub senatu, także twierdzenie filozoficzne uznawane przez przedstawicieli danej szkoły za nie podlegające dyskusji.
2. W teologii katolickiej zdanie, które Kościół na mocy decyzji swego Urzędu Nauczycielskiego lub papieskiej albo soborowej definicji uznaje jednoznacznie za objawione przez Boga, dając równocześnie do zrozumienia, że zaprzeczenie mu oznacza popadnięcie w herezję. Dogmat nie podlega odwołaniu, choć w związku z tym, że ponadczasowe objawienie łączy z elementami uwarunkowanymi historycznie, może zostać poddany tzw. aktualizującej interpretacji lub "zapomniany" (przestaje być przywoływany).
3. W teologii prawosławnej dogmat rozumie się podobnie jak w katolicyzmie, jednak prawo jego stanowienia przysługuje wyłącznie soborom. Ponadto Kościół prawosławny nie ogłasza dogmatów, które nie są bezpośrednią interpretacją faktów przedstawionych w Biblii (dlatego np. odrzuca katolicki dogmaty o niepokalanym poczęciu NMP).
4. W religioznawstwie określenie końcowego etapu ewolucji doktryny religijnej - ta jej wersja, która uznana została przez hierarchię danej religii za oficjalną i ostateczną.
5. Potocznie osąd lub pogląd akceptowany bezkrytycznie, wyłącznie z racji zawierzenie autorytetowi.

Architektura - etymologia terminu
Słowo „architektura” pochodzi od łacińskiego „ architectura” oraz od greckiego „αρχιτεκτονική” (architectu) i oznacza budowniczy, z kombinacji „αρχι-” (archi-), szef i τέκτων (tekton) budowniczy, stolarz. Podczas gdy główne znaczenie słowa „architektura” dotyczy środowiska budowy, przez rozszerzenie terminu oznacza sztukę i dyscyplinę tworzenia aktualnego planu każdego kompleksu lub systemu.

Dzieło architektury
Obiekt, dzieło architektury, powinien odpowiadać zamierzonej funkcji, celowości technicznej, wymaganiom ekonomicznym i estetycznym, a przede wszystkim, dążeniom i oczekiwaniom użytkowników jego przestrzeni lub przeznaczenia.
Realizacja zadań lub obiektów architektonicznych wymaga korzystania z osiągnięć innych dyscyplin, m.in. sztuki, filozofii, inżynierii, techniki, budownictwa, statyki, socjologii, psychologii, urbanistyki, nauk ekonomicznych. W ciągu wieków zmieniały się zarówno zakres obowiązków i koniecznej wiedzy architekta, jak i samo pojmowanie architektury.

Różne definicje architektury

• Potoczne rozumienie związane jest z pochodzeniem słowa architektura: architectura (łac.), zapożyczonego przez Rzymian z greckiego architekton – budowniczy.
• Według Witruwiusza (O architekturze ksiąg dziesięć) architektura polega na zachowaniu trzech zasad: trwałości (Firmitas), użyteczności (Utilitas) i piękna (Venustas)
• Według Egona Eiermanna (Grosse Architekten): Architektura nie ma nic wspólnego ze sztuką, stanowi czysty proces rozumowania. Architektura powstaje dziś wedle uwarunkowań ekonomicznych, konstrukcyjnych i funkcjonalnych
• Niektórzy ze współczesnych neomodernistów (jak np. Vacchini, Snozzi, Galfetti) definiują architekturę, jako rzecz bezużyteczną, która pojawia się dopiero wtedy, gdy potrafimy przekroczyć granice banalnej użyteczności

A zatem: Dogmat architektoniczny
Potocznie pogląd lub osąd akceptowany bezkrytycznie, wyłącznie z racji zawierzenia autorytetowi, definiujący architekturę jako rzecz bezużyteczną, która pojawia się dopiero wtedy, gdy potrafimy przekroczyć granice banalnej użyteczności.

Nadmiar miłych słówek szkodzi

Czy zdarzają się ludzie, którzy nie umieją robić pewnych rzeczy, nie mają wiedzy albo doświadczenia? Pewnie, że się zdarzają. W każdej firmie. Dla ich dobra i dobra ogólnego muszą oczywiście ten stan rzeczy zmienić. I tu się zaczyna irytująca zabawa w konwenanse. Słyszałem już następujące eufemizmy na niekompetencję:

• obszary rozwoju
• rezerwy
• deficyty kompetencyjne
• ograniczenia

Nie mówimy już zatem: Kolego, według zebranych przeze mnie informacji musisz nauczyć się tego i tego oraz zmienić to i to zachowanie, teraz mówimy: Kolego masz fantastyczne rezerwy w tym i w tym. Czy ktoś widział lepszy sposób na ogłupianie ludzi?

Wydaje mi się, że czasem przesadzamy w owczym pędzie za byciem milusińskim. Trzeba wyraźnie powiedzieć, że udzielanie informacji zwrotnej nie polega na byciu miłym. Szok, co? Tak samo jak software craftmanship nie polega na pakowaniu wzorców wszędzie tam, gdzie się da. Tak zwana pozytywna informacja zwrotna nie polega na spijaniu sobie z dzióbków. Pozytywna oznacza to, że informowany osobnik wie dokładnie jakich zachowań się od niego oczekuje. Czyli nie mówisz Kolego, nie potrafisz pisać czystego kodu. Dziękuję, lecz analogicznie do przykładu w poprzednim akapicie: Kolego, oczekuję, że Twój kod będzie napisany zgodnie ze standardem spisanym w...

Eufemizmy, miłe słówka blokują rozwój ludzi, bo dają im złudzenie, że wszystko jest w porządku, podczas gdy nie jest. Jeśli więc jesteś szefem i po udzieleniu po raz setny "miłej" informacji zwrotnej zwalniasz programistę, to wiedz o tym, że to ty ponosisz winę za tę sytuację. Dbając o to, by było miło uniemożliwiłeś człowiekowi poprawę.
Rozwój to proces przechodzenia przez fazy komfortu i dyskomfortu. Jeśli zawsze jest ok, to rozwoju nie ma.

Żeby nie przegiąć w drugą stronę. W/w nie oznacza bycia "nie miłym", nie oznacza złośliwości i braku delikatności. W/w oznacza przede wszystkim bycie rzeczowym, mówienie wprost, odnoszenie się do rzeczy a nie do osoby i troskę o ludzie.

User friendly

Właśnie dostałem poniższy komunikat....to się nazwa user friendly UI :)

What do we play in projects?

Once upon a time there was a team consisting of a few developers. They got down to their project with real passion.

They believed that the best way to learn is to learn from mistakes, so they regularly had retrospection sessions to discuss issues such as:

• consistency of estimating and expectations
• test coverage and its effectiveness
• number of bugs detected in the test phase
• code readability

and a few other things. They had real fun, because they felt that they developed in their specialty. Based on those retrospections they came up with some rules and standards. All the team members agreed that these regularities enable them to work more effectively, so they employ them eagerly. They set up their own Wiki, in which they listed all the standards to be applied by the team, and which they later modified to keep pace with the changing needs and experiences.

Due to the fact that their work was exceptionally smooth, the project sponsor started to hire new and new and new developers to join this team. The first team members became its leaders and then managers. Everything went off really smoothly. Of course, the new people in the department (because, naturally, the team developed into a department) were obliged to learn the existing and proven standards, and apply them in a strict manner.

After some time our managers noticed that these requirements were not fully met. They had problems with forcing the developers to apply the standards. It took them a long time to come up with a solution to this situation. Because they were seasoned engineers, they approached this issue in a strictly analytic way and came up with a formula. According to this formula the employees’ premium depended on the degree to which they conformed to the standards. For example: for 80% test coverage you get +2% of premium, for 50 tester-reported bugs you get +1.3% of premium, and for estimating maintained +3.2% of premium… What a bright idea…

And then the GAME started.

Rules

The intention of the managers was to reward the team for keeping conformity with standards and to encourage the employees to apply them. Nevertheless, the managers completely unconsciously started a GAME with the following rules:

• team members are the player
• you win once you earn the biggest amount of money
• the rules for getting money are specified by the standards applicable to the team

It soon turned out that developers and testers were seasoned players. They would often win…, but:

• test coverage was perfect, but: getters and setters were tested, the tests were disturbing instead of being helpful
• developers provided perfect estimating every day, but they were very, very, very pessimisti
• testers found dozens of bugs, but most of them were about double spaces in labels, missing full stops, etc.
• coding standards were obeyed, but whenever possible, the developers coded as they deemed fit
• retrospections declined; standards were not further developed, they finally became inapplicable to the then situation and impeded the work

What the heck happened? - the managers asked - We really meant well!

Conflict of values

A fellow methodology expert who specializes in analyzing the value hierarchy among employees (it happens that the companies want to know what counts for you: development, professionalism, safety, career, and in what order) was so kind as to tell me in detail that no serious test collates professionally-valid values with values such as family or health, because in such a case the former ones always fail.

When the test does not fulfill this rule, we end up with falsificated data, because the test results will always sway in the direction of family, health, etc. It seems logical that when I have to choose between my career and a permanent damage to health, I will always be driven by my self-preservation instinct, and I will protect my health even at the expense of my professional development.

In this particular team the managers made this specific methodological mistake. Because, if I choose between fitting in with estimating (even if we have to overestimate a little bit) and Christmas gifts, the former one is the perfect choice – no matter what! This is not about us being bad or cheating. Nothing of the sort. That's how we are construed. The borderline between just estimating and overestimating is quite fluid and we easily find the rationale for crossing it. In my opinion, the one to blame is the one who has made such goings-on possible rather then the one who really does it.

Disastrous consequences

Due to the fact that conformity with standards was only the managers’ means to achieve a different goal, the standards were neither further developed nor improved. Nobody felt that it was necessary. Why should we change and complicate the ways to earn money if we already know how to win?

Cash motivation is OK, but only on condition that all human activity boils down to earning money. Take salespeople. In simple terms, a salesperson deals with selling products/services and gets a commission for any bill that he/she brings to the employer. It will work. But what if a salesperson gets commission for the number of meetings that he/she arranges? Then, again, the GAME starts. It may turn out that, OK, there are meetings, but with companies that will never become our clients. Who is responsible for that? First and foremost, the one who developed the GAME.

When your employees have a creative type of work (in this case these are programmers) and the rules and standard must evolve and improve with them, you mustn’t make their salary dependent on the degree to which they conform to the standards. Otherwise you will kill their creativity and work rules will soon become stiff.

Obey standards, because it’s worthwhile

For the standards to work and evolve, they have to be important simply because they are standards. People have to be aware of their value, want to obey them, and see that they make their work better. This is the way our first team members from the image above had worked.

In such a surrounding the standards will evolve and the people will be willing to develop them. Otherwise you will run the risk of implementing the standards on your own, forcibly or through the newly employed members of Committees for Standardization, which will only complicate the rules of the GAME. Then no one will know what is the general idea of it.

And what about money?

We can summarize the situation that I have described here in the following words: Motivate not by cash, but pay them well…:) There’s nothing awkward in it – when the basic needs are not satisfied, there’s no sense to think about the higher ones. Of course, we all need a sort of a golden mean, because any budget is limited.

“To pay well” does not mean “to pay more than a competitive company does.” It may be even less than in the competitive company, but if you give your employees some non-cash incentives, it will work. Still, I agree that this is a very individual case and it makes no sense to generalize, as it may be unjustified.

Grunt, to prostota

Dostałem ostatnio grę edukacyjną dot. szybkiego czytania. Tak się podekscytowałem nową zabawką, że aż straciłem nad nią kontrolę. Było to tak:

czwartek: Dostałem zestaw płytek. Zaraz po szkoleniu pobiegłem do hotelu i pierwsze co zrobiłem, to szybko rozpakowałem CD1 i chcę uruchamiać.
Nie idzie. Zorientowałem się, że zmieniłem notebooka na mniejszego i nie mam CD.

piątek 16.30: Ciągle myślę o nowej grze. Znam już na pamięć instrukcje i teksty z okładki. Już bym pograł, a tu jeszcze parę godzin podróży z Wrocławia. Wykombinowałem, że wezmę laptopa żony, zgram zawartość płytki, przekopiuję na swojego nooteboka i już. Zaraz potem pomyślałem, że pewnie taka gra zajmuje sporo miejsca i potrzebuje płytki do rozruchu. Wpadłem więc na pomysł, że na drugim laptopie zrobię obrazy, które potem przegram i podmontuję u siebie. Genialne!

piątek 22.00: Znalazłem darmowy program do emulowania napędu DVD. Odpalam Nero...hmm moja wersja robi tylko obrazy *nrg. Obrazów ISO nie robi. Ściągam inny program, który robi już obrazy ISO.
Już miałem kliknąć, ale program informuje mnie, że ma własny bardziej skompresowany. format zapisu obrazów i że ISO jest do bani. Googluję. Ok, więc dla testu przygotowałem dwa różne obrazy: ISO i ten drugi: różnica w rozmiarze = 2MB. Zdecydowałem się jednak na ISO.

piątek 23.50: Obrazy gotowe idę spać.

sobota 13.00: Obrazy mają ponad 4GB. Na mojego pendrive nie wejdą. Szlag! Spróbuję udostępnić pliki poprzez sieć.

sobota 13.45: Dwa Win7 za nic w świecie nie chcą się zobaczyć przez sieć. Powyłączałem wszystkie antywirusy, zapory, filtry i takie tam. Nic. Wygooglałem, że z moim routerm WiFi jest coś nie tak i nici z udostępniania. No trudno. Wystawię przez FTP.

sobota 14.15: Też lipa. Nagle mnie olśniło. Mam dysk zewnętrzny! Przekopiuję na dysk a potem do siebie.

sobota 14:17: No tak. Kiedyś chciałem się łączyć z tym dyskiem przez WiFi i producent zmusił mnie do sformatowania go jako FAT32. Przygotowane ponad czterogigowe obrazy tam nie wejdą. (Zaczynam żałować, że zająłem się informatyką. Gdybym znał tylko ofisa oraz guziki power i reset, to bym komuś za to zapłacił i miałbym z głowy, no trudno).
Podjąłem męską decyzję: przekonwertuję dysk na NTFS i po kłopocie. Google mówi, że polecenie winda ma wbudowane polecenie convert i po kłopocie.

sobota 16.00: Polecenie convert zgłasza błędne sektory dysku, co uniemożliwia konwersję. W eleganckim komunikacie zapewnia mnie, że po wykonaniu polecenia chkdsk będzie ok.

No więc wykonuję polecenie chkdsk, które raportuje błędy i pyta czy naprawić? No, pytanie! Naprawiam. Znów odpalam convert. I znów lipa. Nie można przekonwertować z powodu błędów. Partition Magic napewno sobie poradzi! (żona zaczyna domagać się zwrotu laptopa, jeszczę chwilunia)

sobota 16.30: Sciągam Partition Magic. Odpalam, wybieram partycję, konwertuj na NTFS, ok.....Partition Magic odpala program convert! Efekt do przewidzenia. Grrr!!!!!

sobota 17.00: Po chwili poszukiwania ściągam Norton Disk Doctor. Teraz już będzie ok! Zaznaczam autofix Disk Doctor leniwie rozpoczyna naprawę niemal terabajtowego dysku. Dla uspokojenia tematu poszliśmy z żoną na zakupy.

sobota 21.13: Wciaż naprawia...

sobota 23.40: Dalej naprawia...

niedziela 9.07: Naprawił. Odpalam convert. AAAaaaaaaaaaa!!! Wciąż to samo. Googluję, googluję, googluję. Mam! mój dysk ma ustawiony dirty bit i stąd te kłopoty. Znalazłem jakieś polecenie windozy, które sprawdza ten dirty bit. Odpalam - brak praw do wykonania operacji.

Olśniło mnie, wszystie poprzednie sztuczki nie działały bo programy nie wprowadzały zmian na dysku z powodu braku uprawnień. Tylko dlaczego o tym nie informowały? Tajemnica.

niedziela 11:30: Odpaliłem konsolę na prawach administratora i chkdsk a potem convert. Robi się.

niedziela 12.00: Taaak! Przekonwertowane. Przegrywam obrazy, montuję, instaluję, działa. Na wszelki wypadek sprawdzam rozmiar danych na płytce: 154 MB....!@#*&Y#*! Dlaczego nie robiłem tego na początku?

Wnioski

Chwila refleksji nad moją przygodą, która do złudzenia przypomina mi sytuację, których doświadczam podczas prac programistycznych.

Błąd 1: Brak planu
Nie przygotowałem się do akcji. Nie określiłem jakie działania podejmę - robiłem wszystko jak leci. Nie ustaliłem czasu, który mogę przeznaczyć na to zadanie. Wszystko, co robiłem było totalnie nieuporządkowane.

Błąd 2: Zosia Samosia
Plusem i minusem jednocześnie programistów jest kompetencja. Cokolwiek jest związane z IT potrafimy się w tym odnaleźć. Napisać program - ok!, Postawić sieć - no problem!, poskładać komputer - pewnie! Ponieważ, czujemy się kompetentni w niemal całej branży i mamy feeling jak się zabrać do większośći tych rzeczy, to niechętnie prosimy o pomoc. Ignorujemy zasadę buy, don't write.

Błąd 3: Brak feedbacku
Podejmowałem coraz to nowe działania, mające dość znaczny wpływ na stan mojego przedsięwzięcia, bez rozważania neatywnych konwekwencji. Działałem na chybił-trafił.

Błąd 4: Ignorowanie intuicji
Pierwsza myśl była dobra. Mogłem przynajmniej sprawdzić, czy to zadziała.

KARDYNALNY Błąd 5: Brak koncentracji na wartości biznesowej
Koncentrowałem się na rozwiązywaniu lokalnych problemów technicznych. Już na samym początku zapomniałem o gównym celu tego przedsięwzięcia, czyli: zagraniu w grę edukacyjną. Żadne z moich działań nie dodawała wartości biznesowej. To był marsz ku klęsce.

MiernotaFactory

Przez jakiś czas poszukiwaliśmy praktykanta :) Pomijając marnujących mój czas luzaków, którym zdarzało się nie wiedzieć, czym zajmuje się firma albo nawet na jakie stanowisko aplikują (serio! wysyłają cv do 20 firm, a potem wędrują od rozmowy do rozmowy), większość z nich ma oczekiwania finansowe, których nie powstydziłby się developer z dwuletnim stażem w łódzkiem.

Trafiło mnie na miejscu, bo nie dość, że trzeba delikwenta wszystkiego nauczyć, to jeszcze trzeba go najpierw sporo oduczyć. Nie mówię wcale o supertajnej wiedzy merytorycznej lecz o punktualności, odpowiedzialności i doprowadzaniu spraw do końca. Merytoryka to osobna historia.

Wyprostujcie mnie proszę, ale gdy ja starałem się dostać na praktyki (a było nie dalej jak 8 lat wstecz), to mało komu przychodziło do głowy, że może chcieć wynagrodzenie. Słowo! Szczęśliwców z roku, którzy załapali się na płatne praktyki do P&G czy IBM można było policzyć na palcach jednej ręki.

No nie mogę przeżyć, że ktoś chce poprzychodzić miesiąc albo dwa, nie robi nic co można by jasno przełożyć na zysk firmy, zazwyczaj kosztuje, bo trzeba mu poświęcać czas i chce tyle kasy, co regularny programista.

Ktoś mnie jednak olśnił. Podobno za samo studiowanie kierunku technicznego można dostać stypendium z jakiegoś ministerstwa. No to sprawa jasna...

Boję się tylko jednego, że tego typu rozleniwianie narodu skończy się produkcją defaultowych miernot z wyższym wykształceniem. Miernot bez pasji, pracowitości, wytrwałości, chęci nauki. Miernot ze sprzętowo wbudowaną roszczeniową postawą wobec świata. Gdybym wierzył w państwowe ubezpieczenia społeczne, to bym się zaczął bać.

Dziedziczenie zasobnikowe i inne idiotyzmy

Wrzucam przykłady fantazji w dziedziczeniu, które spotkałem (serio!) parę lat temu. Pierwsze można nazwać dziedziczeniem zasobnikowym. Od razu widać co zrobił kreatywny programista. Pisząc fragment systemu raportowego potrzebował przeczytać dane z pliku properties, a że pamiętał coś takiego ze Struts2, to beztrosko sobie odziedziczył.



Drugi kwiatek jest nieco trudniejszy. Dlaczego okrąg dziedziczy z punktu? Otóż dlatego, jak wyjaśnił autor koncepcji, że punkt jest środkiem tego okręgu…

7 Kroków Zła w Projektach IT

Wersja PDF

Czy zastanawiałeś się już jak to się dzieje, że na początku projektu jesteś maksymalnie zmotywowany, piszesz wspaniałe testy (wszystkie są oczywiście green-bar), używasz swojego najpiękniejszego stylu kodowania, klasy, interfejsy metody, ba! nawet pola mają swoją własną, niepowtarzalną odpowiedzialność. Rysujesz piękne diagramy, używasz wzorców projektowych w rozsądnej ilości, a Twój kod czyta się jak najbardziej przejrzystego ebooka. A potem...potem pojawia się niewielki, ledwo zauważalny zgrzyt, mała rysa na wspaniałym krysztale projektu. Ignorujesz to, bo przecież nic się nie stało. Rysa rośnie, a przez nią wsączają się kolejne niedociągnięcia i niedoróbki, aż po jakimś czasie nie poznajesz już tego wspaniałego projektu, siadasz do niego z największym obrzydzeniem i myślisz tylko kiedy to się skończy? Lecz projekt się nie kończy, wciąż są nowe wymagania, wciąż trzeba go utrzymywać. I to, mój przyjacielu, jest Programistyczne Piekło!

Jako przestrogę podam Ci kilka prostych wskazówek jak się tam znaleźć. Ścieżka prowadząca wprost do Programistycznego Piekła jest szeroka, gładka i bardzo prosta. Wystarczy siedem kroków.

1. Bądź obojętny
   Czy to ja powinienem zająć się tym //FIXME? Nieee, to nie ja pisałem, niech ktoś inny to zrobi.
   Czy często zdarza ci się rozumować w ten sposób? Jeśli tak, to gratuluję! Osiągnąłeś pierwszy poziom wtajemniczenia. Obojętność wobec niewielkich rys na projekcie to początek drogi w dół. Być może pomyślisz: oj, jeśli w jednej klasie będzie niewielki bałagan, to przecież nic się nie stanie. Pamiętaj, że małe rzeczy się kumulują. Nie zauważysz od razu różnicy pomiędzy metodą nazwaną divideByTwo(), a div2()
   , bo łatwo umyka wśród reszty kodu. Lecz z pewnością dostrzeżesz różnicę za pół roku, gdy tego typu nazewnictwo będzie obecne w całym projekcie. Ziarnko do ziarnka...
2. Bądź w miarę wierny swoim ideałom
   Cóż, w zasadzie stosuję wzorce projektowe...to znaczy w niektórych projektach. Tych w domu. Piszę też testy...prawie wszystkie przechodzą. Piszę zgodnie ze standardem kodowania...właściwe to w 30%, bo reszta jest niepotrzebna. Odpowiedzialność? Taa, fajny koncept, ale moim zdaniem....
   Znasz to? Czy uważasz, że techniki programowania obiektowego teoretycznie są bardzo dobre ale faktycznie się nie sprawdzają? Jak wyrobiłeś sobie takie zdanie? Acha, przetestowałeś to, rozumiem. Wiesz, to że nie działają, to tylko jedna możliwość. Druga to taka, że używasz ich niewłaściwie. Co wybierasz?
3. Postępuj zgodnie z procedurami
   Pokrycie kodu ma być co najmniej 90% więc w tym tygodniu już nie muszę pisać żadnego testu! Ta metoda jest nieczytelna...no, ale CheckStyle się nie czepia. Diagramy muszą być tylko do istotnych elementów systemu...moja jest chyba nieistotna?
   Procedury, reguły, zasady są dobre. Precyzują sposób pracy i optymalizują sposób wytwórczy. Często jednak, niemal automatycznie, uważa się, że stosowanie procedur w zupełności wystarczy, zatem można zwolnić się z myślenia. Kłopot w tym, że nawet najbardziej wyrafinowane zasady nie przewidują wszystkich sytuacji, które mogą wystąpić w życiu. Bardzo wiele problemów, z którymi się spotkasz, nie da się rozwiązać za pomocą Księgi Procedur używanej w twoim zespole. Jednak z każdym z nich można sobie poradzić przy użyciu zdrowego rozsądku.
   
4. Graj dla zespołu
   Nie wychylaj się. Bezkrytycznie akceptuj opinie bardziej doświadczonych kolegów. Postaw cele zespołu nad swoimi własnymi
   Przede wszystkim: dlaczego pracujesz w tym zespole? Wymień dziesięć przyczyn. Zrób to teraz!
   Jeśli praca, która wykonujesz nie jest zgodna z twoimi osobistymi celami, nie prowadzi cię do jakiegoś wyżej postawionego celu, to prędzej czy później, zaczniesz sabotować to, co robisz. Krok po kroku, niepostrzeżenie, zaczniesz wprowadzać w życie misterny plan obniżania jakości swojej pracy. Być może już teraz warto wybrać się na rozmowę z samym sobą.
   
5. Dziel się odpowiedzialnością
   Jest błąd w mojej części kodu? ...ale Paweł kazał mi tak napisać...powiedział, że będzie działać...
   Zadziwiające, że jeśli chodzi o sukces, to chętnie podpisujemy się pod nim sami. Jeśli chodzi o wzięcie odpowiedzialności za błąd i niepowodzenie chętnie dzielimy się odpowiedzialnością z innymi.
   
6. Ceń ludzi takich jak ty
   MY programiści i ONI analitycy. MY javowcy i ONI .NETowcy. MY od kluczowego projektu i ONI od maintenance. MY starzy pracownicy i ONI nowi...
   Dzieląc swoich i innych sprawia, że nadajemy grupie osób wspólne cechy odróżniające ich od nas samych, czyniących w jakimś stopniu gorszymi. Etykietowanie zapewnia poczucie bezpieczeństwa i porządkuje świat. Daje złudzenie, że nie zginiemy w zespole jako indywidualność. Jak na ironię, takie postępowanie likwiduje indywidualność członków zespołu i blokuje efekt synergii, obejmującą ludzi nic nie znaczącą etykietą oni.
   
7. Wierz w najlepsze rozwiązanie
   Ok, pracujemy w Agile, teraz już będzie dobrze. JEE rozwiąże wszystkie problemy. Nowy framework sprawi, że praktycznie kod będzie pisał się sam.
   Gdyby istniało rozwiązanie/technologia/framework rozwiązująca wszystkie problemy to już dawno by zostało wymyślone i żylibyśmy w świecie, w którym nie byłoby wojen, nikt nie przekraczałby prędkości, a programy by się nie zawieszały. Nie istnieje najlepsze rozwiązanie (w ogóle). Co najwyżej może istnieć rozwiązanie najlepsze, w sensie: najbardziej odpowiednie i optymalne, w danej chwili, dla danego problemu, w danym zespole. Jedyne co może zrobić nowa technologia, framework, biblioteka, czy język to przenieść ciężar problemu w inne miejsce. To coś jak dźwignia pozwalająca zużyć mniej energii do uzyskania tego samego efektu. Pamiętaj jednak, że zawsze istnieją dwie strony medalu. Coś co rozwiązuje jedne problemy zazwyczaj generuje nowe.
   

Tekst powstał z inspiracji artykułem Philipa Zimbardio Evil's Seven Step Seduction Scenario opublikowanym w Charaktery 9/2008

Antywzorce w pracy programistów: Wymyślanie koła na nowo

Zastanawiam się czy wymyślanie koła na nowo ma sens. Ktoś napisał, że jeśli ma być ono bardziej okrągłe niż dotychczasowe to tak. Trudno odmówić sensu temu stwierdzeniu. Ja rozumiem je jako udoskonalanie istniejących rzeczy. Proces udoskonalania jest oczywiście dobry i potrzebny. Jednak podczas programowania „wymyślanie koła na nowo” nabiera czasem nowego, złowieszczego charakteru.

Większość problemów, z którymi się spotkałeś została już rozwiązana. Większość bibliotek, które opracowujesz po nocach została już napisana. Większość algorytmów, które wymyślasz w przypływie twórczego geniuszu już została opublikowana. Dlaczego więc nie korzystasz z tego bogactwa wiedzy?Napisałem „większość”, uwzględniając fakt, że „są na niebie i ziemi rzeczy, o których nie śniło się filozofom".

Jeśli Twoje, z pasją tworzone, autorskie rozwiązania mają charakter edukacyjny albo zwyczajnie robisz to dla własnej satysfakcji – tym lepiej dla Ciebie. Nauczysz się czegoś ciekawego i będziesz dobrze się bawić. Lecz jeśli pracujesz i zależy Ci na wydajności – korzystaj z dorobku innych. Pamiętaj, że ludzie po prostu kochają dzielić się swoją wiedzą i doświadczeniem. Gdyby było inaczej, nie mielibyśmy w internecie żadnej grupy dyskusyjnej.

Kłopot w tym, że większość uczelni kształcących programistów zniechęca do korzystania zewnętrznych bibliotek. No, bo po co używać JGAP w programie skoro można napisać algorytm genetyczny samemu? W ciągu pięciu lat takiej metodyki nauczania studenci nabierają dziwnych nawyków nieoptymalnej pracy, a potem przyjmując studentów do pracy musimy ich tego oduczać...ech...

Antywzorce w pracy programistów: The error is out there

Wersja PDF

Coraz częściej dochodzę do wniosku, że sposób pracy programistów nie został jeszcze całkowicie zbadany. Lawina, którą zapoczątkowali Gang of Four zbiera coraz większe żniwo. Zaczęliśmy od wzorców projektowych w tworzeniu kodu, dalej już popłynęło wzorce w projektowaniu stron www, wzorce J2EE (w innych technologiach pewnie też), wzorce integracyjne, wzorce, wzorce, wzorce...

Nie sposób zauważyć, że choć odkrywanie wzorców projektowych przebiega bardzo ekspansywnie, to jednak ogranicza się on tylko do jednej płaszczyzny: umiejętności technicznych. Nietrudno odgadnąć przyczynę tego stanu rzeczy, wszak pracujemy w konkretnej technologii, za pomocą konkretnych narzędzi i biegłość w praktyce jest gwarantem naszej atrakcyjności jako profesjonalisty w zawodzie.

Pracując z programistami w trakcie szkoleń, jako zewnętrzny konsultant, czy też jako członek zespołu, zauważam, że doskonalenie naszych umiejętności i poszukiwanie wzorców powinno odbywać się w co najmniej dwóch płaszczyznach. Pierwsza – wspomniane wcześniej umiejętności techniczne – rozwija się bardzo ekspansywnie. Druga – umiejętności nietechniczne (mniejsza teraz o nazwę) – trzeba przyznać, że trochę kuleje. Nie tak dawno pisałem o tego rodzaju umiejętnościach w artykule Metaprogramy w tworzeniu oprogramowania. Od tamtej chwili rosła we mnie chęć poszukiwania dobrych praktyk programistycznych na nietechnicznym poziomie. Owa chęć nabiera kształtu w niniejszym artykule. Postanowiłem sobie tropić wzorce w pracy programistów. Ponieważ łatwiej mi najpierw zdefiniować antywzorzec, to od nich właśnie zacznę. Będę wyróżniał postawy i schematy działania, które w moim odczuciu negatywnie wpływają na pracę programisty i jeśli to możliwe będę poszukiwał remedium.

Kilka postów wcześniej pisałem o postawie roboczo nazwanej Job Security, którą z cała pewnością można można nazwać antywzorcem. Teraz czas na drugi, który pozwoliłem sobie nazwać: The error is out there.

Niełatwo zapanować na tym schematem postępowania. Gdy poszukujemy przyczyny wadliwego działania kodu, niemal zawsze przyjmowane jest milczące założenie, że przyczyną błędu jest wadliwie działający framework, lub błąd w bibliotece, lub błąd w systemie, lub błąd współpracownika, lub działanie sił wyższych. Po kilku godzinach poszukiwań okazuje się jednak, że przyczyną zamieszania była literówka. Oczywiście wszystkie z uprzednio wymienionych błędów mogą się zdarzyć, lecz najczęściej wina leży po naszej stronie. Z jakiś powodów programiści odczuwają opór przed zaakceptowaniem faktu, że to oni mogą być przyczyną swoich niepowodzeń. A spróbuj takiemu programiście powiedzieć, że to on jest przyczyną błędu! Zdarzyło mi się parę razy narobić sobie w ten sposób wrogów, więc teraz jestem ostrożny w tego typu komentarzach.
Jak zatem sobie radzić w tego typu sytuacjach? Pytanie trzeba rozbić na dwie części. Po pierwsze, jak radzić sobie jeśli komuś pomagam oraz jak radzić sobie jeśli problem dotyczy mnie samego.

W pierwszym przypadku jest dużo prościej. Tak to już jest, że szybciej dostrzegamy czyjeś błędy niż nasze własne. Jeśli chcę komuś pomóc to unikam mówienia wprost o jego błędach – to zwyczajnie nie działa. Sprawdzają się za to niedyrektywne metafory, np. „Mój kolega też miał podobny problem i...”. Buduję krótką historyjkę o „moim koledze”, w której przekazuję wskazówki odnośnie możliwych rozwiązań. Metoda sprawdza się w 90% przypadków. Pozostałe 10% albo wymaga bardziej wyrafinowanych metod albo trafiliśmy na nieuleczalny przypadek.

Sprawy stają się bardziej skomplikowane, gdy chodzi o nas samych. Kluczem do sukcesu w tej materii jest rozwijanie umiejętności introspekcji. Wyjściowym ćwiczeniem może być tu przyjęcie założenia, że „przyczyna wadliwego działania aplikacji leży po mojej stronie”. Zdaję sobie sprawę, że reguła nie sprawdza się w 100% przypadków, ale w większości tak. Przyjęcie tego wstępnego założenia znacząco oszczędza czas. Dopiero po upewnieniu się, za pomocą możliwie obiektywnych kryteriów (warto poprosić kogoś o przeanalizowanie problemu) można przystąpić do oskarżania bibliotek i frameworków o spowodowanie kłopotów.

Wzorzec Job Security

Prowadząc szkolenia z refaktoringu, coraz częściej natykam się na pewien specyficzny schemat zachowania. Schemat, który napawa mnie przerażeniem i kładzie cień na moich programistycznych ideałach. A było to tak...

Wykładałem pracowicie cel refaktoringu, konkretne techniki właściwe dla poszczególnych warstw i technologii i...nic jak grochem o ścianę - wszyscy uparcie twierdzili, że ich manager w życiu nie zgodzi się na poświęcenie choćby chwili na refaktoring. Przeszedłem więc do broni masowego rażenia - korzyści płynące ze stosowania refaktoringu:

1. Kod jest łatwiejszy w czytaniu


2. Łatwiej jest dokładać nowe funkcjonalności


3. Wdrożenie nowej osoby do projektu zajmuje mniej czasu


4. Testowanie kodu jest łatwiejsze


5. Odnajdywanie błędów trwa krócej


6. Rozbudowywanie projektu zajmuje mniej czasu

A zatem, argumentowałem, potencjalnie zyskujemy najcenniejszy zasób: czas. A czas to, jak wiadomo, pieniądz! Zatem manager musi zgodzić się na rozprzestrzenianie praktyki refaktoringu...

Słuchaj, Michał - powiedział jeden z uczestników szkolenia - jeśli napiszę w czasie krótszym niż mój manager to oszacował to dostanę kolejny projekt. Dodatkowo na projekt zostanie przydzielone mniej czasu, bo już pokazałem, że potrafię pracować efektywniej. I tak z każdym kolejnym projektem mój manager wyciśnie ze mnie wszystkie soki. Jeśli dostanę 10 dni na skończenie projektu, to choćbym wyrobił się w 3, nigdy się do tego nie przyznam. Nie opłaca mi się. Poza tym, mam płacone za każdą nadgodzinę. Im dłużej pracuję, tym więcej zarabiam.
Powiedziałeś, że łatwiej jest wdrażać nowe osoby do projektu. Też mi korzyść! A jeśli nowy będzie lepszy ode mnie? Wtedy ja wylecę z roboty. Piszę mój kod tak, żebym tylko ja mógł go zrozumieć. Być może praca z JSP liczącym 2000 wierszy nie jest zbyt wygodna, ale przynajmniej wiem, że będę potrzebny. Wiem, że będę miał pracę. Refaktoring jest mi zbędny.

Szczerze mówiąc nie wiedziałem co odpowiedzieć na takie dictum...Myślałem, że gdy podzielę się tą historią, to będzie mi lepiej. Nie jest ;/