Blog

Decoding Conference Presentation Titles For Busy Developers

pawelwrzeszcz3 Comments

Have you ever hesitated which session to attend on a multi-track conference?

Here is a short guide that should help you quickly figure out what to expect on a presentation, just judging from the title 😉

Foo Bar and Beyond (or The Future of Foo Bar)

Expect lots of history of Foo bar, slides with a timeline, and a little or no statements about the future. But at least, you will leave the room assured that “Foo bar is moving forward”.

What Is New in Foo Bar 2.0

Agenda:
1. Old Foo bar API sucked
2. We wanted to change it and had a lots of discussions
3. Early preview of new API, with multiple protective statements from the stage that what you see is not yet approved and subject to change (but really cool, indeed)
4. Release date unknown

Live coding session

You will learn how to change font size in an IDE.

In general, the session will assure you that it is still impossible to create an application in half an hour and your work still makes sense.

Foo Bar Anti-patterns

Even though this will be sad presentation, people will laugh every time new anti-pattern is presented.

Unfortunatelly, some of the anti-patterns will be close to your heart. At least hopefully you will learn some cool names for them.

Discussion Panel

Invited speakers will be answering each others questions, hardly ever looking at the audience.

Advanced Foo Bar

Special type of a discussion panel (see above) held in Chinese. The presenter will be either debating with himself or with a small group of Foo bar fans.

Is Foo Bar Dead?

Agenda:
1. Foo bar’s initial success
2. But… there are several issues with it
3. So… is it dead?
4. Real part of the presentation
5. Conclusion: Foo bar is not dead – we just have to care more!

Foo Driven Development

This talk will go beyond TDD practices, which for sure you are doing, but… “TDD is not enough”. There are other xDD’s and you should follow all of them, especially FDD, which provides you yet one more layer of safety (and one more test case to re-write for every small change).

Foo Bar For Busy Developers

Probably a simple tutorial, cause the presenter is a busy person too and had little time to prepare. The title is adjusted in order to attract more people (who is not busy these days?).

If you are really busy, do the tutorial from the website instead.

Other

If a talk does not fall under any of these categories, I do encourage you to identify a new pattern and comment on this post :).

Also, beware that if it is hard to figure out what will be the content, the talk might be a sponsored presentation :evil:.

Enjoy your next conference!
-Paweł

PS Thanks to Michał Ostruszka for the blog post title suggestion.

Advertisement

High-altitude Projects

pawelwrzeszcz1 Comment

Altitude sickness has taught me two important insights about speed and trends, which can be applied to software development projects (and probably many other areas as well).

IMG_5637
Photo: Krystyna Kupiszewska

Altitude sickness

After trekking above approximately 3,000 meters one has to take care not to climb too fast. The general rule is not to ascend more than 300 meters daily to acclimatise.

If your organism does not adapt to the height you reached, several symptoms appear (headache, fatigue, stomach illness, dizziness, and sleep disturbance).

This once happened to me in Nepal. The symptoms usually disappear within couple of hours. However, in some cases they may be getting worse, especially if you climbed significantly more than 300 meters within a day.

Altitude sicknes is quite a simple illness. If a patient is feeling worse and worse the end is always the same – death 😦 The only reliable treatment is to descend.

Speed limit

The first general thing I have learnt from altitude sicknes is existence of hard limit on velocity. Attempting to get above this limit is asking for trouble.

This applies to projects and speed of development as well. I like to keep that in mind when planning software development releases. Usually there is hardly anything we can to quickly achieve higher output (I am not talking about long-term improvements here) and the only reasonable option is cutting down on requirements.

Trends

Moreover, the way altitude sickness develops and comes away shows that it is all about the trends.

For instance, a percentage of code coverage in your project is relevant, but it is more important whether it is increasing or falling. The same applies to more general matters like quality, moods, financial situation and so on.

If we are on the wrong side of the trend, doing nothing and just waiting for better time to come will not help, exactly like in the case of sickness getting worse and worse.

All in all, I find those lessons on velocity limit and trends very useful – much often than in the high mountains.

-Paweł

I used information about altitude sickness from wikipedia and altitude.org. 

This post is a part of short series “What a ScrumMaster Can Learn From a Mountain Guide”. I previously wrote about preparing breakfast and getting up from breaks.

Poking the Comfort Zone @ TEDxWarsaw 2013

pawelwrzeszczLeave a comment

I have never been on a TEDx conference before. At TEDxWarsaw 2013 I have realized what is special about this kind of events – you do not attend them, you experience them.

That is why it is pretty hard to describe TEDxWarsaw 2013 highlights. I will try to list my own, though.

2013-03-29_1122

I got thrilled by Jonathan MacDonald on inclination for understanding everything, which in the end makes us unhappy due to the amount of knowledge to gain rising exponentially.

Jonathan assured myself that it is sometimes OK to say stop to my mind pleading for more details and just experience the thing, even without predictability.

Zofia Borkowska asked a fantastic question after encouraging the audience to sing “Brother John” together – What was that refrained you from singing aloud? What was the thought that came to you after opening the mouth but before starting singing…?

Not being a religious person I got very positively surprised by Małgorzata Chmielewska (standing ovation!). For me, her presentation was not only about “Patching up reality”, but about the power of doing rather than planning.

Aga SzĂłstek, apart from showing an amazing example of user-centered design, taught me the importance of iterating the prototypes.

Mikela Eskenazi got me scared with a vision of everything mobile and online, but fortunatelly only until afterparty when we exchanged our thoughts 🙂

Cezary WĂłjcik on Poland – a must see for everyone in here as soon as the talks are online. I loved both the drawing on how we block ourselves from growing and the story about the camels.

Kristin Pedemonti – I cannot describe her phenomenom in words. HUG!

-Paweł

Introducing a Change – Stand Up and Make Room

pawelwrzeszcz1 Comment

Being a leader may sometimes feel like being an ambitious guy trying to sell the idea of getting up after the break and continuing hiking uphill to the group of exhausted backpackers.

How to make them stand up and go?

Stand up first

There is no other way. Just talking about any idea you want to sell to others will not work. You have to give an example, be the first one.

A mountain guide willing his group to stand up, stands up first, with a backpack on his shoulders, ready to go.

Photo courtesy of Krystyna Kupiszewska
Photo courtesy of Krystyna Kupiszewska. On the photo: Jakub Organ

Make room

OK, so we have got most of people standing and almost ready (adjusting their backpacks, talking to each other, drinking water and so on).

Now, a non-obvious trick to make the “process” of starting smooth is to make few steps forward, then call and wait for them to move.

This is important because:

  • if you just start walking you may end up walking alone and
  • otherwise, if you just stand and wait right next the whole group you are actually blocking the way you want them to go.

Introducing an organizational change

From my experience introducing a change in the team or an organization usually requires following similar scenario. If you want others to adopt a practice, after showing them an example, you need to make some room for them to start.

Understanding this is important if you want people to self-organize, or even just take over some responsibilities.

A very simple example might be introducing a habit of documenting important things on a wiki. Or keeping an eye on continuous integration system. To make this ultimately happen you need to stop doing all of it yourself  (not to walk alone) and stop reminding about this every time. Otherwise you block room for progress.

-Paweł

PS This post and a previous one are part of “What a ScrumMaster Can Learn From a Mountain Guide” – something that may become a short series.

What a ScrumMaster Can Learn From a Mountain Guide – Preparing Breakfast

pawelwrzeszcz1 Comment

Having experience as a mountain guide helped me understand how teams work in various situations. Some of the behaviours apply to the professional world as well.

P1080194.sized
Photo courtesy of Tomasz Rosiek

Imagine you wake up on a sunny morning in the tent piched on the mountain pass. The first task for the group, after crawling out of their sleeping bags: prepare something to eat.

Process

You may count on some people being very helpful (or hungry ;)) and eager to spread jam on slices of bread, but most of your team is probably yawning or hesitating what to do.

What you need to do is:

  1. Start working – cutting the bread, vegetables, etc.
  2. Encourage others to join (inviting by name works best)
  3. Withdraw after short time, let someone else cut the next cucumber.

The most important (and the hardest) part is 3. It is easy to get involved into something, but there are probably more important things waiting for you (campfire, water supplies, plans for the day, oh, lots of stuff). If you do not start leaving work for others you will quickly end up doing more you can manage.

Tools

I have encountered it over and over again – some people do not pack knives. They are generally willing to help, but they do not have a crucial tool. I ended up bringing spare ones on each trip :evil:.

Your responsibility as a leader is to start, show an example and ensure people have everything they need to acomplish the job. After that do yourself (and your team – in the long term) a favor by taking a step back.

Why Write a Blog?

pawelwrzeszczLeave a comment
Question grunge
Š Artaniss8 | Dreamstime Stock Photos & Stock Free Images

The goal of this post is convince myself to start writing. Argh, wrong. To evaluate whether this is something I want to do 😉

So, why have a blog? I could think of a couple of reasons:

Get recognition to get a better job
Well, not for me since I am not interested in leaving my company.

Self-learning
Sounds good, but I somehow associate such a motivation with learning technical stuff and my current focus is more at soft skills. Still worth considering, though.

Fun & enjoyment
Oh, I love writing. I have recently rediscovered how much I like it, while doing copywriting for new SoftwareMill’s website (sssshhh…).

OmmWriter, which I am using at this very moment to transcribe my thoughts to words, makes the whole act a unique experience.

Change the world
or, at least, part of it. I am not sure whether I want to do that 😉 However, there are things I do not like around me, including the world of IT. With my experience I could inspire change in someone else and this is rewarding.

Get recognition – once again
For other reasons, like spreading the word about my company in a cost effective and enjoyable (see above) way. That sounds good.

Building self-awareness, getting my mind around various useful subjects
I would say this is more or less the same as self-learning, but labeled that way somehow looks more appealing to me. I may also learn something new (or discover I am completely wrong) from the responses.

OK, fair enough. Fun, self-awareness and recognition works for me, probably in this order 🙂 I am not promising you anything, but I believe now I have convinced myself, writing will be easier.

How about you? Why do you (not) write a blog?

-Paweł

Retrospectives and Experiments

pawelwrzeszczLeave a comment

On team retrospectives this point seems to be the hardest one – deciding upon specific action points. Gathering data and discussion are much easier parts 😉

Experiments

Here is an approach to make commitment for the action points a bit easier – make them experiments.

Try an idea for a week and see if it works. Put a clear timeframe after which an experiment is collectively evaluated by the team.

Our case

During company retrospective at SoftwareMill we had a discussion on improving our (remote) communication and we were considering using Mumble. Not everyone (including myself) was sold to this idea, but we decided to install it anyway and asked everyone to give it a try.

What brought me round to do the experiment was Tomek Szymański‘s reply to my concerns:

“How can you say you do not like it if you have not tried it?”

Within two or three weeks of experiments we ended up with a different tool (TeamSpeak gave us better quality). For some of teams it turned out bo be their favorite communication channel, other teams decided not to use it, but at least they made a decision based on their experience instead of speculations.

How does it make a difference?

This approach is especially useful if the proposal for an action point breaks the current habit or is somehow unusual, which makes some of the retrospective participants concerned about it. An experiment is a better idea for such a case than trying to enforce a solution.

For a team making the commitment for just a week or so is much easier. And maybe at the point of evaluation (which may happen on the next retrospective) those who were concerned will change their mind.

Give it a try!

So, next time you are stuck on a retrospective try conducting an experiment 🙂 Let me know how it worked for you.

-Paweł

My Talk @ GeeCON 2012

pawelwrzeszcz1 Comment

Tomorrow I am giving a talk “Visibility Shift In Distributed Teams” on GeeCON conference in Poznań.

Presentation abstract

Slides

If you are one of the geeks attending this great Java conference, join me in Room 8 at 11:30 to learn how working remotely looks like and what happens when an agile team gets distributed.

See you there!

Devoxx 2011 Quotes

pawelwrzeszczLeave a comment

A bunch of highlights from Devoxx this year that I would like to present here cannot be opened in any other way than this one:

“Don’t go to the conferences”
      – Martijn Verburg aka Diabolical Developer

The best way to improve your skills is through endless practice. For a programmer, working on code should be the main way to get better in his craft. So, make sure you learn at work, not only at conferences.

“Stop sleeping, start awaiting!” – Johan Haleby

Awaitility library demonstrated by Johan solves one problem with writing tests for asynchronous components and does it in a very elegant way. An example of friendly DSL that allows you to wait for an operation or condition instead of using Thread.sleep() looks like this:

await().atMost(5, SECONDS).until(costumerStatusIsUpdated());

“Have you ever bought bottled water?” – Brian LeRoux

The shortest answer ever for a question on how making money from open-source is possible.

“Think in flows, not features” – Joe Nuxoll on UI design

Cannot agree more. Even though this means taking much harder route than just designing screens, it is worth it.

“We need to start at early stage” – Trisha Gee on women in IT

I am not sure about the exact wording – what counts here is that increasing number of women in IT is not about changing hiring policies at companies (there simply not a lot female programmers around now). Good question to ask is why majority of school age girls do not even consider Computer Science as their possible career path (image issue?). More on Trisha’s blog

Pawel

JAXLondon – Lessons Learned

pawelwrzeszczLeave a comment

Last week I have attended the JAX conference in London. Here is a couple of highlights that attracted my attention enough to write them down.

Product Backlog

Roman Pichler about the Product Backlog:

Low-priority backlog entries should be much less detailed than those on top.

When (and if) their time comes, they will be probably split into smaller stories. This also shows that the backlog is something designed to be often changed (and reviewed!).

Why do you need to allocate time for gathering requirements/design/architecture work every iteration?

Think about the Waterfall approach and all the work done in the initial project phase, before coding. When following Scrum methodology this work still remains. The only difference is that it is now scattered among the iterations.

Guess the number

Jason Gorman came up with a great exercise during his Keynote. 2 teams were trying to guess the 4-digit number, taking turns.

? ? ? ?

One team was made to guess the whole number up front, while another one were free to guess it digit by digit.

Now, Dear Reader, guess who was able to figure out the number faster and which team represents the Waterfall and which one is Scrum 😉

Jason also pointed out that when building a software solution “how fast we learn is actually more important than how fast we deliver”.

Measuring effects of TDD

In the introduction to his talk, Keith Braithwaite showed a correlation of Cyclomatic Complexity values against the probability of faults being found, which I find really useful to convince myself to think twice before adding another “if” into code. And, yeah, at some point the probability reaches 100% 😉

Keith’s analysis of Cyclomatic Complexity distribution in various open-source projects proved that in the tested code one can observe higher preference for less complex methods, though there still remain parts of code of high complexity.

What is more, a nicely TD-Designed project’s code needs somehow express the same behaviour as the codebase with lots of “if” statements. How is this richness achieved? Well, maybe we trade off here more interactions (and greater coupling!) for less “ifs”.

We are all lazy

Last but not least, I found one explanation on why writing tests leads to shorter methods really interesting. Long methods may not be hard to write, but they make testing difficult. Big tests are hard to write indeed. So, when it comes to writing (long) test cases, your laziness forces you to… refactor for smaller methods, cause this will simplify testing!

The best presentation I have attended on the second day was Thinking Distributed to Improve Agility by Jamie Allsop, but… that is another story.