On Sunday, while writing the blog entry for Monday, I tweeted (or is that ‘twoted’?):
One of these days I’m going to write a blog entry on how I write blog entries. You are going to be surprised.
That cliffhanger triggered some responses from people that wanted to know more. So, I took the writing process of my Tuesday’s blog entry as an example to describe the process of me writing a blog entry.
I hope you are not going to hate me after reading this.
Continue reading On writing blog entriesHuib Schoots asked me the other day whether I was on a blogging spree. I provided him an answer. Well, I answered him over twitter. So, it was more than a shallow answer. I told him that he was only seeing side-effects of what I tried to do. Actually an example that he should focus on my outcomes rather than the outputs. Here is the longer answer.
Continue reading Why I am writing so many blog entriesWhile visiting the CONQUEST 2010 in Dresden, Germany, I noticed something while wandering the large pavements in this city. Each time I had to cross the streets at traffic lights, I noticed that I had to stop, press the button for the lights to turn green – after some time. This morning on my way from the hotel to the conference place, it struck me, that this steadily slowed down my own progress. Each time I had to stop at the traffic lights, I was considering what needed to be improved in order for me to make more progress on my way to the conference building.
That was when I realized that the buttons on the traffic lights needed to be pressed each time. If I didn’t press it, the lights for the walkers wouldn’t turn green. This is a clear difference to some of the lights I know from home in Bielefeld (which does exist, just saying). There were pseudo-buttons which you could press or not press, but the lights still turning green. The difference to Dresden now is, that as I was approaching another traffic light, I needed to stop, press the button and wait for the lights to switch, if there wasn’t already someone waiting for it – which turned out to be rarely the case; thus the waiting.
Then I realized, that the button in fact is a similar to a quality gate in more traditional processes. At each gate you have to wait, you have to synchronize back with other parts which are then integrated. But in either case, you seem to have to wait. Then I asked, how would a pseudo-button for quality gates look like? Well, that’s easy, if you do small steps, tiny improvements, and integrate early, often, or even continuously, then you have a pseudo-button. In fact this is the case on Agile projects. You get the feedback from the unit tests during test-driven design. You get the feedback from the story-tests before checking in your changes to the code base. You then get the feedback from the CI-server which runs the tests. On another step you get the feedback from Product Owner and stakeholders during the iteration demonstration or sprint review meeting.
Now, all these feedback loops exist as an automated quality gate. You get the feedback, that you broke something, and you immediately know on what you have focus your immediate attention. On the other hand, when you don’t get any feedback, you also know that everything might be fine, and can continue your work. (This should be the case most of the time.) Quality Gates are automated to large extends in Agile development for good.
Over the last two days I took the opportunity of silence at work to be able to work focused. Since I’m currently reading Growing Object-Oriented Software, Guided by Tests from Steve Freeman and Nat Pryce I tried out their approach while retrofitting some unit tests to some of my test classes.
It took me between one and two hours after lunch to get the first class under test. Implement a unit test, bring in the necessary support code, run the test, make it pass after dealing with some stupidities on my own, then go on. In the end when I felt I was done and couldn’t think of yet another test (I also had checks for exceptions in place by that time), I started a code coverage build to see, which passages of the code I was missing. I got surprised to see that all the tests passed and I had brought in 100% code coverage. 100% line coverage, 100% branch coverage, there wasn’t anything left for the unit testing on that class. Since we also used the class for quite a while I knew it was functioning in our test harness, so I was done with it. I checked in the new unit test and drove home happily. That feeling of pride after polishing up your Technical Debt was a great moment. It felt (and still feels) great.
One thing actually stroke me: My tests were very clear and readable. I was tempted to show them everyone. Since the offices are rather empty during this time of the year, there was no one I could annoy with my pride. I got reminded on Enrique Comba-Riepenhausen on the Software Craftsmanship conference in London in February. He stated during Adewale Oshineyes session, that his customer were on-site to the degree, that they were able to actually read the production code. I felt that I had just a piece of code that my customer would be able to read. (I don’t think so, in retrospection.)
The essence of writing maintainable automated checks lies in writing them clear. Indeed, you should write your test code more clearly than your production code to keep them vital and in shape to serve you during your further development efforts. Unfortunately, teams underestimate the value their test automation brings them when written and maintained properly. There is not much magic about it. But you better take care for your test automation code, or you’ll get trapped in the automation pitfall.
Yesterday I finished reading through Apprenticeship Patterns – Guidance for the Aspiring Software Craftsman from Dave Hoover and Adewale Oshineye. Personally I met Ade at the Software Craftsmanship conference in London earlier this year and participated in his session on Mapping personal practices. After I came back I used the format for Personnel development. Since May I have a video from Ade open in my browser tabs on How to walk the long road, which I still haven’t seen, yet. So, just after finishing the book, I decided to describe my personal development as a reflection of the last four years of my life using the pattern language provided in the book. So, here it is.
Continue reading My Long RoadThis blog posting will serve as a catch-all for the web-pages I left open on my tabs during the last few weeks. In case you’re interested in what I did since the beginning of August, it might be worth a read for you.
Back in July Mike Bria posted an article on Test objects, not methods. His lesson boils pretty much down to one single quote that I need to remind myself of:
Keep yourself focused on writing tests for the desired behavior of your objects, rather than for the methods they contain.
Over the past weekend Michael Bolton came up with a final definition on checking vs. testing. Lately I argued whether or not we need a new name for testing. Michael Bolton was able to explain to me in this post that we do not need a new name, but a proper definition. This definition in combination with Perfect Software gives you pretty well insights into what to expect from testing and what to expect from checking. Adam Goucher summarized a talk from Chris McMahon at the Agile 2009 conference with the following insight:
The only reason to automate is to give expert testers time to manually test.
Ivan Sanchez stated that there is another area where a term got lately abused with vague definitions. The term is “done” and he calls for stopping redefining and redefining it. Basically my experience shows that the same is pretty much true to a lot of words in our business. Lean, Test, Done, Agile, …. maybe you have more of these for the comments.
On my way home today I thought over a job profile I read over the past month. Basically when transporting it to my company I would include “You know the difference between testing and checking” in the skill list.
Finally Matt Heusser put up another test challenge. What I loved about it was the fact that I could more or less directly relate the lesson to my daily work. So it’s nothing really artificial if you build the bridge between the abstract challenge and your real-world project. Oh, and of course, for a geek like me it was fun. Wonder, if I could do the challenge in the real-world, once. I love lightsabres. And as a black-belt member of the Miagi-Do school I had to take that challenge, of course. Feel free to exchange some thoughts on the challenge with me if you have taken it.
Dave Hoover just raised an interesting point on personal improvement: Spend 50% of your working time on personal improvement. Basically I found myself in that blog post. Since about two years – since I have been asked for taking a leadership responsibility – I am constantly reading books in my spare time. Over the last year I started to read several mailing lists and blogs. I am thankful to have married a wife over the last year that is patient with me (I wonder how long she’ll stay that way).
What shruggs myself is the fact that Dave states it takes about five years to see the return on that investment. Five years seems to be a very long time. Reflecting over my life so far I must say, that I have spent more than five years already on improving personally. At the age of 15 I choose to lead a youth group at our local sports club. In my spare time I gave swimming lessons over the past thirteen years and also grew into the leader role at my sports club over the past 15 years. In the meantime – while making my diploma at the university – I was involved in three clubs at a time. Through all these I made great experiences in leadership and organisation. Over ten years I participated and helped to organise helpers for our season openings of our local open air bath. This was a great time and helped myself improve for my current job.
On the other hand I even worked for money at a local store during my university years. There I had to organise the order process for soft drinks, juice and later even alcoholic drinks. I had to organise according to market and seasonal demands and manage the surpluses. In the end there was a major rebuild of the store where I was highly engaged in. Over the years I had learned how to work together with my colleagues and contribute to critical work that is daily business at a local store.
All these experiences were a major part of the preparation for my current position. In the past I have been working with people, for people, sometimes even against people if I was convinced from the opposite. Taking some spare time now to support my journey towards mastery is just a little duty for me. Personally I just took out my calculator and tried to calculate the time that I might have left for my family with Dave’s proposal: One week has 168 hours, 6 hours per sleep each night, two hours for getting to work and back, two hours for eating, 40 hours of work, 20 hours for personal improvement leaves you with 42 hours of time you may spent with your family and for leisure activities like sports. This seems ok to me, but don’t blame me for my naive assessment of the situation. (My wife is working in retail sail and usually does not come home until 9pm due to this, so don’t try to project my situation onto you.) Take Dave’s point into account to at least try it out for a while. Personally I consider myself more of the former group of people in his statement:
I think it would be silly to try to force yourself to do it, you’d end up burning out. Really, I’m talking to two groups of people. To those who are already spending their spare time on becoming a better developer, I want you to know that your efforts will pay off, but understand that it will take between 5-10 years to see the most significant benefits of your efforts. To those who want to become a great developer but hold themselves back out of fear of failure or hard work, I hope to inspire you to give it a shot.
and Dave made me feel good about it.
Today I had the opportunity to talk about some of the skills that I needed to learn while becoming a leader. The girlfriend of a brother-in-law is a teacher for primary school. Today I got into a discussion with her about grades in school. During the discussion I thought on where do teachers get to know how to grade a student. Since I had one in front of me, I took the opportunity to ask directly. She stated that there was no education or course during the time she spent on university on this. In Germany there are two years of traineeship for new teachers mandatory. She stated that during that time she learned just a few regarding the grading process. So most of the grading is done on intuition. Interestingly her description reminded myself of the very first few months of my group leader time, during which I had to do a performance review for one of my colleagues. No one had taught me up to that point how to do it, I just had one review so far for myself. There was no course back in university where I could have learned it. During my last ten to fifteen years I have been a swimming trainer and lead the swimming department at our local sports club for some time, but clearly this was the only opportunity where had experience from leading people – and these situations are less context-driven due to its nature of a teacher to a student. Even today it is still hard for me to reflect whether or not I take the proper intuition into account. (The bad news is that most of your colleagues will not take the courage to inform you of your bad decisions.)
Right before starting to write about this article, I noticed that there is a similar case for good versus bad code. What did I learn at the university about code? What had I learned about bad code? Good code? Most of the insights I have today come from my experiences at work. When I started about three years ago we had an undesigned test automation framework. There were lots of script functions without intent. Whenever I needed to put in something new, I had to go out look for the right place to do so. Additionally I was never fully aware if there already was a similar function that I should have been extended, decomposed, refactored to meet my new requirement. This was a mess. Over the past year I was able to get rid of this grown framework and introduce and grow a new one.
We focussed on good aspects of code there. Using test-driven development, refactoring and regular reflection while evolving our classes. This was a good practice and we even tried to avoid most of the deficiencies from our previous experiences. Over the last year we had some contributions from a team that did not follow your initial approach. The result is that there are currently two ways to do things. When inspecting the code I can now see the difference between good code I wrote, bad code I wrote and very bad code from that I permitted to be included into the code base. (There was an up in the findbugs remakrds, a down in the code coverage and an up in the crappyness trend after the commit operation. The bad code was visible.) The main problem is that my colleagues do not seem to bother, where the broken window rule comes in. There is much work left to do and I know that I will have to take the responsibility to clean up this mess.
The point that is striking for me is, that there is no education on these things that matter most during day-to-day work. You do not get taught the stuff to grade your students. You get able to do so by getting experiences, intuition and your own guts and hunches. Similarly there is no education for a good or a not so good worker. You have to trust yourself here. The same goes for the cleanliness of code. Despite the books I could mention (the one with just that name), there is no preparation in university for clean code. Similarly there is little to no education on good tests or not so good tests. From my perspective a major challenge for craftsmanship – be it software craftsmanship or even testing craftsmanship – is to teach these difference in an apprenticeship. This is our profession and our job to do in the years to come.
Last week I had an experience outside work, which I could relate to work. Finally I decided to share this in my Journal. Beside remaining posts in this category I decided to make this one public.
On Tuesday I had a discussion with club mates about training in swimming. In my city there are several swimming clubs combined together into an organization for supporting talent scouting. About ten years ago I noticed that the philosophy of my swimming club and the philosophy of the clubs around us differ in one particular point. Most of the other swimming clubs following the rule to have training lanes separated according to the age of the trainees. From 6-8 the kids shall learn how to start swimming, from 7-9 they learn back stroke beside breast stroke (which they started with), and so on.
Our local swimming club follows another philosophy. We pretty much believe that each step needs to be taken regardless of the age of the trainee, but based on his achievements so far. A quick learner at the age of 12 can quickly move forward to the fastest swimmers, and a more slowly learner might be trapped on one training lane for two years or longer.
Jerry Weinberg taught me to be aware of the threat/reward model of modern psychology. Therefore I won’t argue one over the other. Instead I say that there are some advantages to one form of teaching swimming and organizing a swimming club (technically) over the over and vice versa. The point I would like to raise here, is that you may get stuck when sticking too much with one model. This one I noticed in the discussion we had last week. There were several pleads during the discussion, where I could not understand the argumentation, since I had a different model in mind. Basically I realized that the other parties seemed to be trapped in their model, that they did not see the problem. Yes, this is an occurrence of the No-problem syndrome.
How does this hold to work? Currently I need to prepare a discussion at work, where one of my colleague has a model of how stuff works in mind and I have another one – a different one. We tried to get an approach already last year, but soon got stuck in the discussion on a more personal level. Our superior decided by then to refuse the discussions and have both parties follow their model. During the retrospective of one of our projects the point was raised to stick to one approach to exchange team members from both groups more easily. I take this point very seriously, but based on the past year struggle to prepare for this. Both of us seem to be stuck in their mind model and do not see the solution through copulation. While reading through “Becoming a Technical Leader” I already realized this one, and decided to prepare a spike solution to have a better basis for further discussions at hand.