Agile leadership: results

A couple of weeks back I have reached out for help for my MSc thesis about leadership in organisations of different size. I have received 200+ responses overall, and 166 complete, usable responses based on which I managed to complete the following report:

Leadership in Agile

A big thank you goes out to all of you who made this possible. Thank you for your time, response and support; I am really thankful to all of you.

Advertisements

Agile leadership: request for participation

For the past months I’ve been researching what characteristics an Agile Leader needs in companies of different sizes, for my MSc thesis. I’ve now reached the data collection phase. If you are working in an Agile team, please fill out the following survey to help my work. It will not take more than 10 minutes.

In return, I promise to make the results available here on this site, as soon as I finish writing.

The link is here: https://goo.gl/forms/361nss6U5snIpJpn2

Thank you in advance!

Notes to myself: free CD pipeline for home projects

I’ve been building a little home project for the past couple of months, just to experiment with programming languages and frameworks. During this time I managed to put together a simple continuous delivery pipeline, completely automated and free of charge. In the following paragraphs I’ll describe how I, in my next home project should connect those pieces of puzzles together. Maybe it will be useful for others as well. Continue reading “Notes to myself: free CD pipeline for home projects”

Comparing web services for output equality

The other day I had to figure out a way to compare two different web services to see whether a subset of their output are equal or not. One of these services (let’s call it the legacy service) is capable of emitting XML as a response, while the other one (a completely new service that is intended to be a replacement for the legacy code) uses JSON. Unfortunately, the output of these two are only similar in a conceptual way; their structure differs a lot, they use very different ways of structuring data. I checked out some common frameworks for testing web services, and though all of them were useful for parts of my task, they proved to be hard to use for my complete work. Of course, all these frameworks all all too general purpose, while my problem is, I guess, not that of a common use case. At this time I started experimenting with REST Assured – a framework that finally saved me a lot of time and effort. In the below short post I will describe how easy it was to get my job done in a relatively short time, with this cool framework.

Continue reading “Comparing web services for output equality”

Design patterns in the real world: Strategy

Quite some software engineers think that design patterns are some overly complicated, mythical, abstract things that bring no practical value to software development. This is unfortunate. In order to prove they are indeed something real, in this (and some upcoming) post(s) we are going to take a look on a few examples on how real software products implement some of the GoF design patterns. Today, we are going to visit Strategy, from HotSpot’s point of view. (See the previous post about Flyweight here).

Continue reading “Design patterns in the real world: Strategy”

5 easy ways to write hard to test code

 

Once I heard a talk, where the presenter asked the audience how would they write hard to test code on purpose. People in the room were a bit shocked, as nobody would write bad code intentionally. As far as I remember, they couldn’t even come up with very good answers to this question.

Of course, the purpose of this question was not to educate people on how to code in a way that makes their colleagues’ lives harder. Knowing what makes code hard to test can help avoiding some serious problems. Here’s my list of answers to the above poll (of course it’s really subjective, almost everyone has a different set of smells that they hate most).

Continue reading “5 easy ways to write hard to test code”

Design patterns in the real world: Flyweight

Quite some software engineers think that design patterns are some overly complicated, mythical, abstract things that bring no practical value to software development. This is unfortunate. In order to prove they are indeed something real, in this (and some upcoming) post(s) we are going to take a look on a few examples on how real software products implement some of the GoF design patterns. The first one to be examined is Flyweight.

Continue reading “Design patterns in the real world: Flyweight”