piątek, 31 października 2014

Michael Feathers' visit

In May this year I had the pleasure of hosting Michael Feathers at Motorola Solutions in Krakow. We invited Michael to do a kind of extension, in the form of workshop and a lecture, to his great and well-known book "Working Effectively with Legacy Code".

Michael's skills are very rare as not only is he skilled in teaching the methods of dealing with legacy code, but he also feels comfortable with doing so in C++, in addition to Java and C#, which both are more pervasive among XP professionals.

It was a great experience and I think many of us will remember some of the ideas we learnt during this visit.

piątek, 24 października 2014

Agile in metaphores: angle of repose

This is my latest idea for a nice exercise that could be used during an Agile / Scrum or XP training for a development team. You are welcome to copy this idea and use it in your training, especially if you give me the credits :-)

Every loose material has a property known as the angle of repose. It is the angle that is naturally formed when a material is loosely spilled out, for example to be stored:

The task:
Give the development team an amount of loose substance such as salt of sugar and ask them to produce a measurement of the angle of repose of that substance. Then leave the room. Give them a protractor and leave the room.

Conclusions after the task is executed:
When you are back in the room, the engineers will have hopefully measured the angle in the experiment of spilling out the substance and measuring the angle more or less accurately. Explain to them that although a theoretical computation of the angle is possible, it would be extremely complex, compared to simply doing the experiment they have just done.

Then, this metaphore could be extended to cover topics like:
  • empiricism as the method for solving (complex) problems (even if this particular is just complicated)
  • TDD - experimenting with the production code to see when it passes a test, rather than trying to mentally execute it
  • developing a story based on unclear or incomplete knowledge of scope, in order to get feedback, rather than struggling to understand and "lock" all of the story first

czwartek, 16 października 2014

Career advice: where do you want to be (and in what order)?

In one of Capers Jones' books (I think this was "Estimating software size") I came across a categorization of software projects that looked interesting to me. It put kinds of software projects in relation with the ability to perform the same tasks without a computer. Although I'm not able to cite it, it was something like this:
  • all tasks can be performed without a software system; computers are used only to make it easier or faster
    • bookkeeping in a small company could be an example 
  • tasks can theoretically be performed without a software system, but they would require so much time and involve so much risk of human error, that it would be extremely impractical or close to impossible to perform them without using computers
    • finding items in an extremely large collection (e.g. a huge library) could be an example
    • some banking operations could be even better example
  • tasks cannot be performed by a human by their very nature; there must be a software system in place in order to perform them
    • controlling an embedded device or processing physical phenomena are examples of this
One could ask oneself which category would be good one to work on projects in. Probably the brightest and most ambitious would aim at the third category or, if they are not able to get there, at least the middle one.

But we can look at the domains and the categorization from a different angle. Some projects require deep domain knowledge that takes years of hard work to build, others have rather simple, self-explanatory domain, known from everyday life to everybody. Would it sound logical that people working on this latter category tend to focus more on programming skills (languages, patterns, XP practices), whereas those working in a complex domain focus more on the domain itself and as long as the system works, they do not aim to become world class clean coders? It definitely sounds logical to me. It may simply be explained by the amount of effort and energy that is needed to understand the domain, so that no time is left to focus on programming skills. Or there may be other reasons. Regardless of that, one can expect that the simpler the domain is, the more chances of bettering the programming skills will be available.

We can join these two views to say that a programmer is likely to advance their programming skills working on a project that is supposed to help users in something that is generally doable without a computer. Conversly, those working on a system that can do things of which human is incapable, will not be capable to extend their programming skills much.

Where do you want to be and in what order?

sobota, 11 października 2014

You need to know: tail end recursion

A few years ago I did a small quasi-prepared-Kata exercise to demonstrate differences between programming in (and thinking in) different programming languages. I chose a simple state machine as an example and implemented it in Common Lisp, Java and C.

Having programmed in each of these languages at some point in my life, I deliberatly used approach typical for each of the languages. I even exaggerated a little to emphasize the characteristics of languages and how they influence our thinking. For example, I used a little more than needed classes and objects in Java and avoided recursion, whereas in Common Lisp, the state machine was transitioning from one state to another by a recursive tail call.

One of the observers questioned the Lisp implementation saying that it would quickly result in stack overflow. Although I intuitively felt that was not true, I was not able to explain why. Right after that session, I searched for information about recursion in functional languages and I learned about tail end recursion. A nice summary is given here: http://en.wikipedia.org/wiki/Tail_call

I recommend reading this Wikipedia entry, it explains really well things that are often not known by programmers focused on imperative languages.

czwartek, 9 października 2014

Beware of theoretical problems

Anybody who was a change agent or acted as one knows this too well. You meet a development team of 15+ engineers and do an introductory talk on Scrum. Even before you are one third through the talk, there is a question or an interruption from the audience - similar to one of the following examples:
  • this is all very interesting, but how it [Scrum] would deal with a situation when half of the team quits their job on one day?
  • this may work in an experienced team, but imagine that you have a team where there is just one experienced developer and all others are fresh graduates
  • I don't understand why you are against my idea of recording the stand-up meetings; sometimes the amount of input from the team may be too large for the Scrum Master to remember
If you hear that (and it could be on any meeting you talk about change, not necessarily about Scrum), don't engage into discussion.They are all extremely theoretical questions that will NEVER happen in real life. What's more, whatever process / approach / tool is used today, it is most likely unable to resolve these theoretical problems either. As a change agent, you just have to hear it out, but don't begin discussing it.