Polish version

In today’s post I want to talk about topic, that is not 100% technical, so I encourage to read it not only by programmers.

When you start doing a new project, you want to do it quickly. After all, time is money. But not everyone knows how to do project quickly.

How NOT to do

When I was a beginner in programming everything was clear and simple: I start making a first feature, I try to do it as quickly as I can, and then start a next feature. I don’t waste time for improve something, that works. I don’t waste time for keeping a clean code.

With this mindset at the beginning of project a progress in work is very noticeable. But problem is, that every new features is somewhat connected with these, that was written previously. If we have left a mess in code, now we need to work in this mess.

We add new features, project grows, it is more and more complicated. We start to get lost. It is easy to remember what code written yesterday do, but after couple of months you start to forget. We spent more and more time to understanding code written earlier. It happens more and more, that while we are making new feature, we broke old one (because we aren’t aware how some thinks works).

At the beginning of project work progresses fast, but after this it only slows down.

How to do

1st: thinking about future

Programmers must know about project everything they can: what it is supposed to do, how it will be used, what features are foreseen for future upgrowth. While writing code, programmers should think about what will write in future.

But you could ask: is this against an Agile? I anwear: no. An Agile implies, that reacting on changes is more important, that sticking to the plan, but it doesn’t imply, that you should work without any plan. Working with Agile you shouldn’t think about how software will work, but why.

2nd: no hurry

Developers shouldn’t be hustled. Hurry can speed up current part of project, but will make you problems in the long run. It even has it’s own name: technical debt – because it is like taking a load: now you have more money (working features), but in future you will need to pay interests.

But obviously there is a problem: how can client (that is not a programmer) can see, if developer work slowly because he work carefully, or if he is lazy? It is even bigger problem, when client pays to a software house hourly rate (because in this scenario faster = cheaper). In this scenario client could supervise developers, which implies hustling, what makes whole project made slower, so more expensive. Alternative approach is to trust software house, but then there is risk, that workers will spend payd hours on facebook (this is my personal experience, and I have to mention, that although I tried to be honest in registering work hours, it is hard to focus when I see on screen next to me scrolling of memes) and in worse scenario cheating in calculating work-hours (I worked in company that do that).

Personally I don’t see better solution that to avoid contracts, in which client pays developer for hours.

3rd: refactoring

You need to carry about quality of source code, by making refactorization on a regular basis. What can be seen as a waste of time, in big projects it is really a good idea. And i want to note words “on a regular basis”. If you start refactorization after years, you can find problems, that are no longer solvable.

4th: experience

To make big project you need experienced programmer (at least one in team). Freshman (junior developer) even if want to write clean code prepared for future development, will not know how to do this.

Beginner programmer can quickly learn how to do something, that work (he always has access to uncle Google), but only an experienced one knows how not to make troubles for future (if client/boss allows it – see previous points).

Summary

When I write this text I have over 5 years in commercial programming experience (I don’t include hobbyist programing). When I have been working, I allways tried to think how to optimize my work, bot most of people I met don’t think this way. Most of people assume, that hour of work of developer is hour of work of developer and that’s about it.

The longer I work in the industry, the more I realize, how bad this approach is. In this moment I work in project, which already took 15 000 work-hours. I think, it could take 1500-2000 work-hours, if it was done as it should be from the beginning. But in this moment there is nothing you can do to stop wasting time and money, other that leaving project.

So before starting next big project, think about organization of work, to avoid wasting tens of thousands dollars.

English version

W dzisiejszym wpisie chciałbym poruszyć temat mniej techniczny, dlatego zachęcam do przeczytania go nie tylko programistom. 

Gdy zaczynamy robić nowy projekt, chcemy zrobić go szybko. To zrozumiałe, bo w końcu czas to pieniądz. Tylko nie każdy zdaje sobie sprawę z tego, jak to osiągnąć, by projekt zrobić szybko. 

Jak tego nie robić 

Gdy byłem początkującym programistą sprawa wydawała się prosta: biorę się za pierwszą funkcjonalność z listy, robię ją możliwie jak najszybciej, a gdy skończę, to biorę się za następną. Nie marnuję czasu na poprawianie czegoś co działa. Nie marnuję czasu na dbanie o porządek w kodzie. 

Z takim podejściem na początku projektu praca idzie mocno do przodu. Problem jest taki, że kolejne funkcjonalności, które dodajemy, nie wiszą w próżni. Każdy nowy feature łączy się z tymi, które były napisane wcześniej. Jeśli we wcześniejszym kodzie zostawiliśmy bałagan, to teraz w tym bałaganie trzeba się jakoś odnaleźć. 

Dodajemy kolejne funkcjonalności, projekt rośnie, robi się bardziej skomplikowany. Zaczynamy się w nim gubić. Łatwo jest sobie przypomnieć co robi kod napisany wczoraj, ale po kilku miesiącach zaczynamy zapominać. Coraz więcej czasu schodzi na to, żeby połapać się w tym, co już jest napisane. Coraz częściej zdarza się, że robiąc nową funkcjonalność, psujemy już istniejącą (bo nie jesteśmy świadomi jak niektóre rzeczy tam działają). 

Na samym początku praca nad projektem idzie szybko, a potem tylko zwalnia. 

Jak to robić 

Po pierwsze – myślenie w przyszłość 

Programiści muszą wiedzieć o projekcie jak najwięcej: do czego ma służyć, jak będzie używany, jakie funkcjonalności są przewidziane na przyszłość. Chodzi o to, żeby pisząc kod myśleć już o tym co będzie w przyszłości. 

I teraz może pojawić się pytanie; czy to nie przeczy zasadom Agile? Otóż nie. Agile zakłada, że reagowanie na zmiany jest ważniejsze niż trzymanie się kurczowo planu, ale nie oznacza to, że w ogóle nie powinno być żadnego planu. Tyle tylko, że programując zwinnie nie skupiamy się na tym jak ma działać software, ale raczej po co. 

Po drugie – brak pośpiechu 

Programistów nie można poganiać. Pośpiech może przyśpieszyć dokończenie aktualnego fragmentu pracy, ale odbije się czkawką w przyszłości. Fachowo określa się to mianem długu technicznego – bo to działa jak zaciąganie kredytu: teraz mamy więcej pieniędzy (działających funkcjonalność) ale w przyszłości będzie trzeba zapłacić odsetki. 

Oczywiście tutaj pojawia się problem: jak klient, który nie jest programistą, ma rozróżnić, czy programista pracuje powoli, bo pracuje dokładnie, czy po prostu się obija? Jest to szczególnie problematyczne, jeśli klient płaci software house’owi za godzinę pracy programisty (bo wtedy zrobić szybciej = zrobić taniej). W takiej sytuacji klient może albo pilnować programistów – co sprowadza się do wyżej wspomnianego poganiania, co sprawi, że projekt jako całość zostanie zrobiony wolniej, więc klient za całość zapłaci więcej. Może też zaufać firmie programistycznej, narażając się na to, że programiści za jego pieniądze będą przeglądać wykop.pl czy inny joemonster (mówię to z własnego doświadczenia, i muszę dodać, że choć sam starałem się być uczciwy w logowaniu godzin, ciężko się skupić, gdy kątem oka na monitorze innego programisty widzisz skrolowanie memów) a w gorszym wypadku kantowanie w obliczaniu ilości godzin (również w takiej firmie pracowałem).  

Osobiście nie widzę tutaj lepszego wyjścia niż po prostu unikać umów, w których klient płaci programistą za godzinę. 

Po trzecie – refaktoring 

O jakość kodu trzeba dbać, robiąc na bieżąco refaktoryzację. Coś co może wydawać się startą czasu, tak naprawdę w dużych projektach się zwraca. Przy czym podkreślam słowo: na bieżąco.  Jeśli weźmiemy się za refactoring po latach może się okazać, że niektórych rzeczy już poprawić się nic da. 

I wreszcie po czwarte – doświadczenie 

Do robienia dużych projektów potrzebny jest doświadczony programista (przynajmniej jeden w zespole). Świerzak (czyli fachowo mówiąc junior developer) nawet jeśli będzie chciał pisać czysty, dobry kod przygotowany na przyszłe zmiany, to nie będzie wiedział jak. 

Początkujący programista raczej szybko nauczy się, jak zrobić, by coś działało (zawsze mamy wujka Google), ale dopiero doświadczony będzie wiedział, jak zrobić to tak, by nie zakopać się w przyszłości. Oczywiście o ile przełożeni/klient mu na to pozwolą (patrz poprzednie trzy punkty). 

Podsumowanie 

Gdy piszę ten tekst mam za sobą ponad 5 lat, przez które zawodowo zajmuję się programowaniem (programowania amatorskiego w to nie wliczam). Zawsze pracując starałem się myśleć o tym, jak moją pracę mogę zoptymalizować, aby zrobić więcej w krótszym czasie, jednak niewielu ludzi, z którymi współpracowałem, myśli w podobny sposób. Większość ludzi wychodzi z założenia, że godzina pracy programisty to godzina pracy programisty i tyle w temacie. 

Nim dłużej pracuję w branży, tym bardziej uświadamiam sobie, jak bardzo jest to złe podejście. W tym momencie pracuję w projekcie, który trwa już około 15 000 roboczogodzin. Moim zdaniem mógłby trwać 1 500h, max 2 000h, gdyby tylko od początku ktoś wziął się za niego porządnie. Tylko że w tym momencie rozwoju projektu nie da się już nic zrobić, by przestać marnować czas i pieniądze (nie licząc porzucenia projektu). 

Więc zanim zaczniesz robić kolejny duży projekt pomyśl trochę nad sposobem pracy, aby nie marnować dziesiątek jak nie setek tysięcy złotych bezsensownie.