Marek Blotny's Blog

In this post I would like to share with you quite cool logic puzzle. Real purpose of this puzzle is to reveal mental habit which is common for majority of people. I know, it’s very vague but that’s because I don’t want to spoil the fun

The puzzle

Preparation – You will need a pen and a piece of paper. Take the piece of paper and put on it nine dots in a way showed on the image below.

Rules – Your task is to draw four straight lines in way that all dots will be covered. To make it a bit more difficult, all lines have to be connected, end point of first line is a starting point for the second line and end point of second line is a starting point for third line…

Here is an example:

My lines are not exactly straight, but there are clearly four lines.

And that’s it really – now go and try to solve it on your own. There are not that many combinations to check so it should be doable within a few minutes.

Solution

Here you can download the correct way to cover all dots. I hope you have managed to figure it out on your own. If not then don’t worry – solution to this puzzle is far from obvious for majority of people. When I was trying to solve it, only one person of twenty five in a group has done it right. And that’s because that person had seen this puzzle before.

Key thing to notice here, to get it solved, is that you are not limited to area with dots. You can also use space around dots. People tend to make assumptions because “things usually work this way”. Usually in puzzles like that, there are lines representing boundaries, so it’s clear how big the game area is. In this case however boundaries are not defined. That’s something which completely doesn’t fit to scenarios familiar to our mind. And that’s exactly why we have made the assumption – there must be some boundaries, there always are! The easiest thing was to assume that outer dots are closing available space.

Of course that was just a game. Incorrect assumption was made and that’s all! No one got hurt, right? But imagine for a second, what are the consequences of incorrect assumptions made in the beginning of a project? Usually tremendous! Tell me from your own experience – are projects with incorrect assumptions made somewhere in early stages that uncommon?

I work with content management systems all the time. For me customization of CMS to client needs is a business as usual. I have done it many times. We, as a Cognifide, know how to do it and we are good at it. Risk here however is called - routine. With time people tend to stop thinking about basic things and take them for granted. We do make assumptions even without thinking about it. On the other side, our clients, in the same time also make some assumptions – about us, as a service providers, about a project or about a cost. They expect to get some things and this is not always communicated. Why? Maybe because we don’t like to waste time on talking about things which are obvious, right?

This puzzle showed to me that I’m not free from this mental habit; I do make lots of assumptions. It helped me to be much more aware of that. Also I’m aware that our clients are most likely doing exactly the same thing and it’s our job to surface those “obvious” assumptions. That is one of the reasons to keep asking “why?”.

My conclusions

1. Be aware that people simply make assumptions, sometimes even without thinking about it
2. Try to understand client’s intentions and goals to have better chances with discovering hidden assumptions
3. Be conscious and transparent with assumptions which you make. How? The simplest way is to write them down and make them available to everyone.
4. And finally – try to get distance from time to time and challenge your assumptions – try to verify correctness of them. Rule which was correct in past may not apply any more or may not apply to some specific project. It’s worth checking our habits from time to time and adapt if necessary. Seth Godin wrote once that decision before the decision is the box. Try to look on things from outside of the box – challenge your assumptions.

Final words … I’m sure that this game has some name; I have heard about it from a few different sources, it seems to be popular element of different trainings for marketers, sales people or managers. If anyone knows the official name – please leave a comment!
Moreover, if my post has inspired some thoughts in your head and you have enough time to share – please leave a comment!

Sooner or later developers have to start thinking about their career path. They are facing a question like ‘I have been programming for x year … now what?‘. As I see it there are three potential career paths for developers:

1. Well known path from development to project management
2. Purely technical path towards “senior developer” / “technical lead” / “software architect”
3. And finally third path towards technical consultancy

Quite often you can hear that developers are not good project managers. People say that mainly because being a good developer doesn’t make anyone a good leader or project manager. Programming and management require different set of skills.  Majority of developers got technical training and they lack soft skills which are essentials when it comes to managing people. However developers want to “progress” and in some companies this is the most natural way, the most obvious path. Transition to manager requires learning new competencies and changing “point of view” but for sure it’s possible.

Assuming that ex-developers feel good in the role of project manager  they have one big advantage over non-ex-developers PMs – they know what debugging is!

Every software developer knows how to debug code. When something goes wrong they can figure out what the problem is. Once the problem has been identified, they can figure out how to fix it. (In most cases.)

Ex-developers understand software creation process inside out. That puts them in much better position to investigate problems which may occur and solve underlaying issues. For them project is not only about tasks, estimates and tracking progress. They know what is really going on. PMs without technical background usually have following options when the project is in trouble:

• additional people to speed things up
• overtime hours
• functionality descope

Ex-developers are not limited to the above list, this is their strong side!

Yesterday I was on an interesting call with a client. Project for this client is on hold for a while now. At the beginning it was a project like any other, but after one or two sprints a list of blocked user stories started to grow really fast. After the second sprint it was already clear for us that decent cooperation of both sides is a must if we want to have a chance to meet the deadlines. We were very clear about that with the client. Unfortunately client didn’t have time to work with us so we decided to stop entire project, people were moved to the other projects and basically we were waiting for the client to come back to us and unblock further development.

That was the situation until yesterdays call when the client promised to remove all blockers and asked us to immediately restart the project. Our answer was that of course we are happy to restart the project but we need x weeks to get developers back from other projects. Therefore immediate restart is not possible.

The point which I want to make here is that this example illustrates well healthy balance of powers between the development team and the client. At the beginning of the project we have committed to deliver before the certain deadline but it doesn’t mean that entire responsibility is on our side. We have an obligation to finish our work within agreed timeframe but in the same time client has an obligation to support development team and find time to answer questions. When client is neglecting his/her part of the deal then we have a right to stop the project.

On the other hand when client is asking for project restart (s)he can’t expect that it will happen immediately. We are partners therefore client has to accept that it’s not our fault that project is on hold and we need time to assemble the team back.

It might be obvious for many people but I have also met number of people who have only one answer to client’s requests: “sure, no problem”. Answering always like this is risky because it goes against the balance and suggests to the client that we are not partners.