Już za 10 dni Agile By Example. Pierwsza warszawska konferencja o tematyce szeroko pojętego "Agile". Na dwudniowej konferencji można posłuchać ludzi, którzy od dawna tworzą ten ruch. Będzie też i "nasz człowiek", Piotr Burdyło, który przedstawi Kontrakty Agile'owe, w których TouK i Piotr w szczególności ma duże doświadczenie.
Pogodzenie "zwinności" i "stałości" korporacji jest bardzo trudnym zadaniem. Piotr opowie jak pogodzić te dwie strony - Software House wytwarzający zwinnie oprogramowanie i korporacje, dla których kwestie prawne i ścisłe trzymanie się ustaleń umów są kluczowe.
Piotr nie jest prawnikiem. Jest praktykiem, który potrafi skutecznie połączyć te nie-połączalne strony :)

Do zobaczenia na ABE 2011.

Pod koniec czerwca miałem przyjemność powiedzieć kilka słów na konferencji Integracja Systemów Informatycznych GigaCon 2011. Z pozostałych prelekcji najbardziej zainteresowała mnie ta przeprowadzona przez pana Jarosława Żelińskiego. Zresztą sam prelegent w jednym z pierwszych zdań stwierdził, że będzie ze mną polemizował (moja prezentacja była wcześniej), czego potem raczej nie robił. Choć sam główny temat jego prelekcji nie był może z punktu widzenia osób tworzących systemy IT odkrywczy, to wszelkie dygresje były bardzo ciekawe, ale … w większości trudno się mi było z nimi zgodzić. I pewnie dlatego były dla mnie ciekawe.

Od tamtego czasu stałem się stałym czytelnikiem blogu pana Żelińskiego. Chciałbym się podzielić kilkoma spostrzeżeniami do treści tam prezentowanych.

Zacznę od drobnej złośliwości. W maju, jako że sięgnąłem też do starszych wpisów, autor napisał: „[...] ja już wyrosłem ze społecznych źródeł wiedzy jakim jest Wikipedia i przytoczę definicję z książek mających konkretnego autora [...]”. A dzisiaj czytam, jak autor krytykuje praktyki Agile … czerpiąc wiedzę na ich temat z tego społecznego źródła wiedzy. Kończąc złośliwość dodam adresując to do autora, że Wiki i Wikipedia to nie to samo i mają się do siebie tak ja klasa do obiektu. :P

To moje łapanie za słówka pokazuje jednak pewien problem. Pan Żeliński lubi zaczynać myśl od „nie jestem wrogiem Agile”, by potem jasno swoją wrogość do tych idei przedstawić. A z wrogością często bywa tak, że jest ona skierowana do czegoś, czego się do końca nie zna.

Z czerwcowej konferencji zapamiętałem pan Żeliński ostrzegał przed zwinną (Agile) integracją, która miałaby polegać na tym, że programistom daje się dostęp do bazy danych a ci (bez jakiegokolwiek zastanowienia) z nowego kodu z takiej bazy korzystają. Co to ma wspólnego z Agile? Otóż idee Agile nie mówią o tym jak ma wyglądać architektura oprogramowania, tylko jak powinien/może wyglądać proces tworzenia oprogramowania. W tradycyjnych (starych) metodykach analityk czy projektant też mógłby programistom przekazać (raczej nakazać), że mają w identyczny sposób taką integrację wykonać. Tyle tylko że, w przeciwieństwie do metodyk zwinnych, od źle wykonanej analizy czy złego projektu nie byłoby wtedy odwrotu, bo przecież zdaniem pana Żelińskiego dobry programista nie dyskutuje z projektantem.

Oczywiście tak jak wiele osób programujących mówi, że stworzony przez nich kod programu jest bezbłędny, dokładnie przetestowany a niuanse platformy mają w jednym palcu, tak i analityk może powiedzieć, że opracowany (odkryty) przez niego model dokładnie opisuje rzeczywistość, jest przetestowany a samą dziedzinę rozumie doskonale. Megalomania albo pokora – wybór należy do ciebie. Błąd można popełnić zawsze. Jednak w tradycyjnych metodykach błąd w analizie jest dużo bardziej kosztowny niż błąd w kodzie programu.

Ten problem dostrzega również pan Żeliński pisząc w innym z wpisów, że „źle wykonana analiza przeciętnie podnosi koszty dwukrotnie a bywa, że znacznie więcej”. Z tym że jego rozwiązanie widzi w bardziej rozbudowanej fazie analizy, co ilustruje diagramem z „kosztowną pętlą odkrywania wymagań”. Jako źródło podana jest firma IBM. Mamy więc tzw. argument przez odwołanie się do autorytetu. Znana firma zrobiła badania (zrobiła?) i z nich wynika założona teza. Bardzo dobry argument… do czasu aż autorytet zmienia zdanie. Bo rozwiązaniem problemów z kosztami wynikająymi ze słabej analizy nie jest (już?) według firmy IBM wydłużanie jej czasu przed fazą implementacji, tylko stosowanie zwinnych (agile) metodyk i choćby  w takim kierunku zmierza sztandarowy zestaw produktów tej firmy wspierających proces tworzenia oprogramowania – IBM Rational.

W zasadzie to może błędnie napisałem, że nasz „autorytet” zmienił zdanie? Może zrobił dokładnie odwrotnie? Bo metodyki zwinne nie polegają na likwidacji fazy analizy, jak wydaje się sam to rozumieć a sugerować innym pan Żeliński, tylko na maksymalnym możliwym jej wydłużeniu, czyli … na cały czas trwania projektu. Scott Ambler (chief methodologist for Agile at IBM Rational) napisał kiedyś, że „analiza jest tak ważna dla praktyków Agile, że robimy ją każdego dnia”. Temu służą planowania, stand-up meetingi. Po to zwinny zespół winien być wielofuncyjny, czyli posiadać więdzę i umiejętności w pełnym zakresie wymaganym do tworzenia oprogramowania, w tym również umiejętności analityczne. Nie są one jednak skupione w pojedyńczych, wyizolowanych osobach, które na dodatek innych przydatnych umiejętności nie mają. Agile to nie brak tak lubianych przez pana Żelińskiego diagramów UML, tylko wykorzystanie ich do przekazywania i uspójniania wiedzy, kiedy jest taka potrzeba, a nie jako (podstawowa) forma komunikacji z zamawiającym oprogramowanie.

I w tym miejscu odeślę do dość już leciwego źródła http://www.agilemodeling.com/essays/agileAnalysis.htm

Here's the video from my presentation and the discussion about Agile Skills Project and our experiments in motivating developers at my company, that I had a chance to show at Agile Warsaw.

Do not ask my why the camera is 100% time focused on the wall, I have no freaking idea :) The voices are there, and that matters.

You can either watch it on Parleys: http://parleys.com/d/2019 or right here. Be warned: it's in Polish.

Unfulfilled programmers

Erich Fromm, a famous humanist, philosopher and psychologist strongly believed that people are basically good. If he was right, then either our society is a mind-breaking dystopia or we have a great misfortune of working in a field that burns people out, because many IT people I know are more like Al Bundy than anyone else.

Why is being a couch potato something wrong? Happiness can be achieved in many different ways, but not by passive pleasures. One way of pursuing happiness is by self realization and while self realization can happen in any activity, it's makes perfect sense to have it at work, where you spend one third of your life time anyway.

But many developers I know, consider work as something boring at best, dreadful at worst. True, programming can be awful, when you have to dig deep into a terrible code base without any perspective for a change, but IT is vast and you can always find something interesting, and once you learn it, you will find a way to make money on it, either by changing position inside your company or changing your employer altogether.

Yet most unhappy IT professionals don't do anything to change their situation. The main reason for that is, because it requires a lot of learning, and learning at home is not the most beloved activity for a couch potato.

So why are developers turning into couch potatoes in the first place? Why the last thing a typical developer will do back home is learning and polishing his skills? There are plenty of reasons for that.

The three main roots of an IT couch potato

First, our work is tiresome. Nearly every job offer you can find mentions “able to work under pressure” and “flexible long working hours” in the requirements. This translates directly to the “burn-out” phenomenon.

Second, the technological landscape is changing overwhelming fast. Unless you work for a slowly adapting institution like a bank, your skills will be outdated in a few years time. Sure the deceased Sun, god help us, granted Java developers four years of relative stagnation, but that's an exception and it's going to end soon enough anyway (unless, of course, these are just convulsions before slow death of technology). You better learn and you better learn fast, or you'll have no other option than to promote yourself into management.

Third, just how long can you sit by your computer everyday? Yeah, I know, some people spend years playing WoW, Eve and alike, barely moving. I am a sinner myself, with Steam reporting over 350 hours in Modern Warfare 2, 200 hours in F.E.A.R. 2 multi, and countless months of my life wasted by Sid's Civilization. But for not-addicted, it's just simply stupid, not to mention unhealthy, to have your ass integrated with the chair. No matter how comfortable it may be. There is more to life than that.

Case Study at my company

It all started with a few SQL programmers grumbling about how they are bored to death, and how they would like to switch to OO programming. I'm not a person who waits, so next thing I did was asking our management if they could move those guys to Java/C# projects. And the management was all for it, with just one requirement: they would have to first learn our technology stack at home, not to be totally lost and unproductive. After all, the more technologies an employee know, the more valuable he is for the employer (think about switching people between projects).

A few months later and nothing has changed. I'm asking sql guys how the learning is going, and I get the answer: it hasn't started yet.

Now, I know the best way to learn something is by hands-on experience at work. After all that's why I've been changing my job a few times: to have a real world experience. It's easier to learn french if you move to Paris. And learning at home is hard because of the aforementioned reasons. The very same reasons, why you get only 650 people on a free conference, like Javarsovia.

So what can we do, then? How about we remove all the obstacles? How about we make learning at home fun, satisfying and profitable. How about we provide  motivation and feedback. How about we also solve the never-ending dissonance between employee's financial and employer's productivity expectations on the way. Sounds interesting? Let's try, then.

First: make it profitable.

Up to some point, people get motivated by money. It won't work if you are already earning enough to pay for everything you need, but in a country like Poland, to be able to build/buy yourself a house, you have to be making many times the average salary. So here, money is still a major motivator. Every year, every developer goes back to his boss and says: I want more.

Guess what, your boss wants to pay you more. No kidding. After all Henry Ford's said:

“There is one rule for industrialists and that is: make the best quality of goods possible at the lowest cost possible, paying the highest wages possible”.

Highest wages. You boss really wants to pay more. But to stay in business, the company needs you to either improve the quality or productivity. Both mean more money to the business, and more money to pay you with. If you consider that, the goal of a developer who wants to learn something new (or get better at something) is on the way to make the company more profitable. After all, this is software development – you never know what technology you gonna need tomorrow.

This works both for completely new stuff, and for learning something that company is already quite good at. If you know several technologies that the company is working with, you are more valuable, because you can handle more projects (you boss may think in terms of reallocating resources).

After thinking about all of this I went to my bosses and asked them: will you pay more to the people who learn different technologies at home? Even when they can't use them right now at work? Will you give a rise to those Oracle guys, if they learn Java?

The answer was: definitely! They actually said that every time a developer asks for a rise, they ask him back: what have you done in the last year to improve your market value? What have you learned? Because every time an employee's market value increases, the company's value increases.

Simply speaking: more skills means more money. Both for the developer and for the company. It's amazing, how often people forget about it. Making it crystal clear can give you a motivational boost to do something at home and a nice perspective. You don't have to switch your job to get a rise. You need to learn more, and they'll happily pay you more.

Second: make it easy

The main question with learning is where to start from? And for software developers it's the most important, most difficult question, because there is no way to learn everything, because spending years studying can be simply a waste of time, if the technology is dead/outdated the moment you get productive with it. What should I learn or why should I learn at all, if the risk of wasting the most precious thing in my life, my time, is so high? How do I decide what to learn.

Lets make learning safe and easy.

Your best bet is to start with something that has much longer life expectancy, something that will help you right away, no matter what a technology you have to work with in your next project. And something that is relatively simple to learn: agile skills.

These are skills of an agile developer, well established, well recognized, and not going away any time soon, because we still do not have anything on the horizon that could surpass them.

Yeah, I know, the world 'agile' is so popular nowadays, that even my grandma is agile, but lets go for a solid list of things agile. No bullshit theory, no marketing mumbo jumbo, give me a precise, distilled and refined list of things I should learn, things that will help me, things worth spending my time on.

Here it is:

The Agile Skills Project

The project is all about self improvement and learning. It's a great inventory of “ isolated, learned, practiced, and refined” agile skills, with definitions, resources, descriptions of steps to mastery and success stories. Take a look at the “Pair Programming” page, for example.

All the skills are divided into different areas: Business Value, Collaboration, Confidence, Product, Self Improvement, Supportive Culture, Technical Excellence. You even get a nice mind-map with it.

This is a single reference point for all those who do not know where to start or where to go next. All these skills are in high demand on the market and with a very long Time-To-Live. The best thing is though: no matter what technology you gonna work with tomorrow, you can benefit from them.

I took the list from the website, tidied it up a bit, refactored it for the needs of my company, and proposed it as a Request For Comment, a wiki page, where everyone gets to discuss and shape up the idea, before we give it to the management.

Soon we had a discussion. It wasn't easy to make everyone understand the concept, but after a while people joined in, and we added some more stuff.

Level up!

The Agile Skills Project is more than a simple index. It tries to create a learning ecosystem, by defining quests:

"Quests" are on-the-job experiments, self-assessments, peer-reviews, course experiences or other activities intended to help a person better apply a particular agile developer skill set.

It's a bit like a Role Playing Game. You have your quests, you do them, you get experience. For experience you get more money and new toys (technologies) to play with.  It's fun. Billions of MMORPG players cannot be wrong.

But to make that happen we need something every game has: feedback.

Third: give feedback

OK, so we have a bit of motivation (money) and a list of goals (agile skills). Who is going to give us quests, and who is going to tell us we did a good job? How will we have our feedback?

The first and most important thing, is to see the results of you actions. Otherwise you loose focus and motivation (money can only get you that far). Therefore you should create a list of quests you have done. Put it on the intranet or somewhere, where you can show it to others. It's important, because you are going to share it with your mentor.

Yes, a mentor. Choose someone from your company, someone you trust, someone you respect. It doesn't have to be an Einstein. Meet with this person once a month, during your work-time. An hour should do. Discuss with your mentor what quests you want to accomplish this month. Could be anything, reading an IT book, learning new programming language or taking another step to master one of the agile skills from the list. Tell your mentor when you'll be done. Meet together again next month, and either put the quest in your done-list, or mark it as 'failed'.

The role of the mentor is to listen to you, remove obstacles, help you choose a good path and give you feedback.

You'll be surprised by how much the meeting with your mentor motivates you. It works much better than money: you don't want to fail in the eyes of the mentor, because this is the guy you respect, and you want him to respect you as well. And once you see your constant improvement by filling the list of quests done with your mentor, it gets addictive.

Smells corporate?

How is this any different to what you can sometimes see in a corporation, with a year long plan of tasks your boss is giving you to accomplish to get your bonus?

Well, first of all, these will be your quests, chosen by you. Second, you will choose your mentor as well. Your boss usually doesn't know a thing about what you are doing. Third, it's all about your self-improvement, not meeting some company goals. You get better at something, the company gets better at something. After all a company is not much more than the people working at it.  Fourth, it's a fast feedback cycle, you do not have to wait till the end of the year to get it.

And finally, it may be a bit corporate, because I have never seen any small company doing anything like this. But even if it is, it still seems like worthwhile. Anything to get me out of the couch.

Discuss

It's a bit too early to tell whether the idea will be successful. We have just started. Fo me it is already helpfull, because with a list of quests done I have have a feeling of progress. If you'd like to discuss this, and other ways to animate software developers to do something more, I'm leading a meeting at Agile Warsaw group about it, on the 20th of September, 19:00. Feel invited.

By the way, here you have a trial of "other ways to animate" from our internal TouK Code Jam Party, we held a week ago. Doesn't look mych corporate, does it? 

Who are generalizing specialists? Why do you want them on your agile team? The term was coined by Scott W. Ambler and describes an individual who is multi-skilled. His definition requires such person to have:

• one or more technical specialities,
• knowledge of software development,
• general knowledge of business domain he works in,
• openness to learn new things.

Ideal Agile team has members with cross-functional skills.  Being fluent in several technical specialities generalizing specialists can help their teams accomplish technical tasks. Their general knowledge makes teams more flexible. Tasks planned for Sprint are coarse grained and there is less need for synchronization. When tasks can be assigned to anyone no queues and therefore no bottlenecks are created. I would say that general knowledge comes from openness and intrinsic curiosity and both serve well any agile team.

In next posts I’ll show you how flexibility affects teams’ performance.

W poniedziałek miałem przyjemność poprowadzić dyskusję na AgileWarsaw na temat zwinnego podejścia do szacowania. Dziękuję wszystkim uczestnikom za udział – mam nadzieję, że mimo późnej pory było to dla Was równie ciekawe jak dla mnie.

Mam nadzieję, że przedstawiony przeze mnie sposób szacowania prac powiększył zasób zwinnych narzędzi. Nie powiedziałem tego wprost, ale trzeba pamiętać, że szacowanie przy tablicy z wykorzystaniem rozmiarów koszulek nie jest praktyką wyraźnie lepszą od planning pokera, ale w pewnych kontekstach może dawać lepsze efekty – jak ze wszystkimi praktykami – każda ma swoje zastosowania. Główne zalety tej metody w moim kontekście to szybkość przeprowadzenia sesji szacowania (czego nie udało mi się osiągnąć pokerem). Dodatkowo wydaje mi się, że jakość (trafność) oszacowań jest nieco wyższa, ale ciężko mi to udowodnić. Tak jak wspominałem na spotkaniu – analiza ilościowa oszacowań i planowanie na tej podstawie jest identyczna jak w przypadku wyników pokera.

Nie udało się nam porozmawiać o możliwości wykorzystania punków funkcyjnych, ale na pewno będzie jeszcze okazja.

Poniżej mindmapa prezentacji.

Do zobaczenia na kolejnych spotkaniach.

Some remarks after attending Certified ScrumMaster Course here in Warsaw. Course was led by Dan Rawsthorne from Danube. Dan has a great experience and he is personally very involved in Agile methods.

The scope for two-day training was quite large. Too large to cover everything in detail so good base knowledge of Scrum was necessary to benefit. I’ve never seen Scrum being done by experienced practitioner. What I liked most was to get the glimpse of how the Scrum process might look like when done by someone like Dan – by the books Scrum is simple, when you do Scrum right you cannot deny it is not easy.

As Nigel Baker was giving his speach titled "10 tips that ScrumMasters should know, (but probably don't!)" at Winter Agile Tuning, Tomasz Przybysz was taking notes on a paper tray. I've heard the talk was pretty good and a few people were trying to copy his tray. Since the original presentation is not yet available, I thought I'll help with putting my own photo (phone quality) on-line.

Maybe Tomek will take a while to put some insight into his notes? What say you, Tomasz?

Click on the image to get the full (readable) size version.

I've found Winter Agile Tuning conference purely by accident, reading someone's blog. I have to admit that I've never heard about it before event though it was a second edition already. As I had ma chance to talk with, Jakub Dziwisz, one of the organizers, I understood why. Jakub didn't think about it as a country wide conference, more like an way to animate local Agile society. Well Jakub, I've counted at least four people from Warsaw and quite a bunch of speakers from abroad, so I believe you'll do well with changing your target audience expectations for the next edition.

Having an Agile conference somewhere nearby (I consider Cracow nearby as it's 3h by train from Warsaw) in a suitable time, is a good enough reason to go. After  I'd checked the website I knew, I cannot let it pass by. The program was interesting, with some well known names (i.e. Szczepan Faber, guy who wrote Mockito, the best mocking library in Java world), it was practically free of charge (50zł) and it was starting at 2pm on Saturday.

2PM! Do you know what that means? It means that you do not have to get up at 5am to catch a train or at 4am to get there by car. You don't have to be totally exhausted, intoxicating yourself with gallons of energy drinks. You don't have to get there a day before, wasting a perfectly sweet Friday night. It means that you get up at 8am, like normal people, you have enough time to eat lunch, and after the conference it's exactly the right moment to go to an afterparty.

I wish all the conferences would start at at least at noon.

Back to the event. I went there with a friend of mine, Tomasz Przybysz, one of not so many programmers I've met, that actually cares about the quality of his work, and as there were two tracks and two of us, we've decided to split and exchange the knowledge during breaks.

I've chosen the 'Craft' track while Tomasz went for the 'People'. That was a pretty good choice of mine and I only wish I could be on '10 tips that ScrumMasters should know...' by Nigel Baker. But let's start from the beginning.

Sweetest acceptance tests

The first lecture was given by Bartosz Bankowski and Szczepan Faber. At the last moment, they've changed the topic of the presentation from an enigmatic 'Be a VIP and rid your WIP' to 'Sweetest acceptance tests'. Can't say I was disappointed.  They took us through an example of working with Sweetest which is a sort of a plugin to a wiki that allows for a very fluid and direct translation between a wiki-defined set of acceptance requirements and automatic (junit) acceptance tests.

How does it work exactly? It's quite simple: you talk with your client, you both write his requirements in a wiki, the tool creates junit automatic acceptance tests for you. Here's a demo.

It fits very well with a TDD/BDD approach and allows you to have a bit more contact with the client, as the client can see on the wiki what his own acceptance requirements are and which are already implemented.

Lately, we've spent two days creating acceptance test scenarios for my client in doc format, which could allow him to formally say 'yes'. We've been doing it by checking his requirements (again), checking whether we have implemented them right, and writing all down.  The thing is, that since we do TDD/BDD, we already have all the tests that tell me whether his requirements are met, because we start implementing a new feature by writing a test for it. The main failure of the situation was that we've been writing those scenarios AFTER the whole project was implemented. Had we had them written down BEFORE, maybe even had them connected to unit tests, we'd be done before we've started.

That's what Sweetest is for.

Not that it's something totally new. If you're doing TDD you are already implementing client's requirements as tests (or at least you should start every feature with a single test for it, and then go down the implementation and Red-Green-Refactor line up to the point when it's fully working and is fully covered), but everything that helps with communication, well.. helps. And as in my example, can save you a few days writing docs.

I've been to another conference in Cracow last year where Szczepan was presenting Mockito framework. Just like the last time, his presentation was vivid, fluent, interesting and straight to the point. That's what makes a happy Panda.

Let them speak in their own language

Next was Konrad Pawlus 'Let them speak in their own language. How we enabled domain experts to build acceptances tests - case study'. Konrad shared his experience with developing Test Driven software for financial market. The clue was to allow domain experts, guys used to Excel, to verify software in a way that was familiar to them.

To do that Konrad (or his team) created a Visual Basic tool, that could convert xls files with example calculation to a scripting language, and then fire up this scripting language in a similar manner to junit tests. At the end, domain expert could verify everything down to the last number (and knowing that Excel actually creates a lot of errors with rounding that is very important), create new tests to check scenarios they never thought about before.

This is quite a cool way to bring customer into testing and have a robust feedback right away instead of getting a lot of bugs and change requests at the end. It's not something new as well, there are frameworks like FitNesse by Robert C. Martin that accomplish this, the thing was that for some clients/projects you need to have an exact Excel equivalence in calculations, which means simulating Excel's errors as well. Even those, the customer is not aware of. That's where it's nice to actually verify everything back with Excel.

Estimation of software complexity in Agile projects

After that came Jarosław Swierczek with his 'Estimation of software complexity in Agile projects'. Now that was quite cool and controversial lecture. Jarosław stated that SCRUM's poker planning is nothing more than an expert estimation, something that have also occurred to me some time before.

Don't be fooled by the 'expert' part, expert estimation is nothing more than calculations based on intuition, something which may work for experienced people and repeating projects, but often end up with pulling numbers out of your ass. Sure, the poker thing helps a lot, having other people verify your 'out-of-ass' calculations helps as well, but it's still intuition. We would wish that it's at least heavy wizardry but it's not. It's not science at all.

Jarosław Swierczek stated that according to some statistics a bit more than 70% of expert estimation is wrong, when wrong means more than 30% difference. Unfortunately I had no chance to ask him where did he have this percent from and I believe that this may not be true for poker planning (does intuition work better for a group?), so it all stays as anecdotal evidence.

Anyway, he was able to show us a nice, scientific formula for estimating complexity and time-cost. Things that were especially interesting:

- You need at least two years of historical data (estimations of complexity and time + the actual results) to be able to do anything more than 'pull numbers out of your ass'.

- You need to choose a formal method of calculating complexity and stick with it (event the Functional Point method is not that bad)

- Complexity has got NOTHING to do with the time it takes to finish something

- How much time it takes, depends your team's performance, which should be calculated from sprint to sprint, which is depending on stuff like technology/experience/distractions, and can actually be calculated by expert method ('my intuition tells me I'm gonna be super fast/slow because I have a lot/little experience in this technology')

Jarosław has got his own consulting company Aion www.aion.com.pl where they help other companies with estimating complex projects, so of course you should be wary about marketing bullshit, but what he presented made a lot of sense to me.

Journey through tests and prototypes

The fourth lecture was given by Piotr Trochim, a game developer (his current linked-in profile shows CD Projekt RED, the company behind 'The Witcher'). Piotr was talking about TDD in game development, a situation which is quite different to typical enterprise/b2b/Internet development in that you create a hell lot of prototypes of different ideas before actually deciding what you are going to put into the trunk of your repository.

Well, we (Internet/intranet software developers) actually create a few prototypes too, especially when changing the technology, so it applies as well to us.

Since creating well written prototype does not pay off in the long run and only slows down the prototyping, Piotr suggested this change is TDD cycle:

- First create a working prototype or a few prototypes (max 4h) if you need to have to choose between something. Don't worry about tests, do it as simple and fast as possible.

- Decide whether the idea/technology is fine to be used on production

- DELETE the prototype(s) completely (never commit the prototype as it is very badly written)

- Now write the solution again, using TDD and best practices

- When you're finished, create a tool to help monitor/debug the solution. This could be anything from stuff as simple as logging annotation (so you can turn logging into debug mode and see what happens), to state visualizers.

For me the most important part was to NEVER commit the prototype and always delete it completely. This is something I've seen way too often, when programmers commit a completely chaotic prototype just because it works and try to extend it later with very poor results. It usually ends in refactoring bigger/longer than actually writing the same stuff the proper way.

It was also interesting to note, that while Piotr is using C++ for development, he creates most of the prototypes in C#, as it's simply easier.

Yeah, I wouldn't like to return to C++. The expressiveness of this language simply sucks.

BDD and Ruby On Rails using Cucumber and Rspec

Last lecture was from Pawel Wilkosz about BDD and Ruby On Rails using Cucumber and Rspec. Frankly speaking I was tired, I don't work with Ruby and using TDD for more than last 4 years I didn't have much to learn in here.  That's where I'd rather be on 'People' track, where all the guests were having an Open Space kind of discussion.

And then there was an afterparty, but that's a completely different story.

You can find official pictures from the conference in here.
All pictures by Krzysztof Dorosz.