Category Archives: Software Craft

Software Craft

Software Craft

Assets of a software craftsperson

1 Comment

During a workshop at 8thLight Justin Martin collected assets of a software craftsperson. He published these on his apprenticeship blog, and I found the list compelling for some extensions. As I went through the list, I noticed that I included most of it in my article Software Testing Craft in the first issue of the Agile Record magazine.

Strong Enthusiasm

Always brightening everyone’s mood with your love of what you do.

Deliberate practice and the enthusiasm to learn something new anywhere are at the heart of my craft. I seek learning opportunities for testing, such as testing challenges, Weekend Testing or Testing Dojos, as well as Coding Dojos, Coding Katas, and Refactoring challenges. Skimming code to seek improvements has become as vital to me as testing a new application for flaws that may bug me later. The life of a software professional is a daily learning opportunity, if you’re open for it.

Don’t be afraid to ask for help

Especially if you feel rushed, or have bitten off more than you can chew.

Everybody tries to be helpful, all the time. Indeed, Jerry Weinberg pointed out in Becoming a Technical Leader that being helpful is a key for becoming a motivational leader. That said, there are two sides of the medal: being helpful and asking for help. In a helpful environment it’s easier to ask for help. But don’t shrug in the non-helpful environments, either. Don’t be afraid about saying “I don’t know”, since it’s vital to know what you don’t know. If you do know what you don’t know, you also know when to ask for help.

Ask a lot of questions

Even if you are already a Craftsman, if you are surrounded by other Craftsman, there will always be new things to learn.

There is a direct connection to the previous point. Asking for help is a special case of asking lots of questions. By asking questions, you start to reflect over the course of what you perceived. Over time, when you get helpful answers on your questions, you are able to learn from the answers, and grow. This is called expertise or experience. By constantly questioning not only the technical facets, but also the process aspects of your work, you develop yourself as well as your mind.

Discipline Discipline Discipline

The mark of a Craftsman is to have an unfailing discipline to do the right thing. Whether that is constantly learning new things, or never forgetting what you know, especially when it is hardest to practice.

Discipline is a key to successful learning. Giving in to feelings of pressure or mistrust is the pathway down to suffering. You need discipline to stay on your course and pursue it. Leaving the safe ground means to go awry. Discipline itself can be separated into three basic components: going slow, doing it right, and being methodical.

Go Slow

Often it is better to take your time, making sure you do every step correctly, rather than rushing for a temporary spike in productivity.

Going faster by going slow, sounds weird, but it’s the paradox key to success. Always remember that typing is not the bottleneck, otherwise we could simply pursue faster keyboards for you. Giving your mind the right amount of slack, saves you from paralysis. Rushing something to success is merely the solution of a novice. Taking the time for steady progress now, rather than a full bloat of erroneous features that you need to fix later, will not help in the long run.

Do it Right

Never stop practicing the things you know that work. Don’t stop testing first. Don’t stop refactoring.

How come we always have the time to do it over, but never the time to do it right? Going slow is the first step in order to make it right. If the software does not work, you can hit any other requirement, but it’s the “getting it to work” that’s the hardest part. Similarly, if your suite of automated checks has a lot of false positives, that is tests that pass, though they shouldn’t, then you will never know whether you can successfully deliver your software, or not. Make the tests and the checks right, or don’t make them in first place. Anything worth doing, is worth doing it right.

Being Methodical

Be thorough. Be certain you are producing the best work that you are capable of through a steady and unflinching practice of virtues.

Taking the time, and making it right, are the first steps in order to being methodical. If you give in time pressure, you are less likely to work methodical and might fall back to cowboy-coding. This does not help. Instead, remember what you learned, the TDD-cycle, the ATDD-cycle, don’t try to run before you walk. Through this you will reach steady progress that helps you and your customers.

Lists

A Craftsman knows his own productivity, and can gage how much he can get done in a certain time span. Making lists, getting metrics, and measuring your productivity will help to accomplish this.

The heart of Agile is to make progress visible. Measuring anything worth measuring, in order to prepare an informed decision later. Craftsmanship takes this a step further. In order to know how much effort a particular project may be, you need to have data from your past. Creating lists based on past experiences may help you with this. Over time you will be able to see patterns, and might no longer find the lists useful. By then you may have reached a new level of mastery – the Ri-level in the ShuHaRi model of skill acquisition or the Expert stage of the dreyfus model.

Understanding the Real Business Intent

It is important to remember you aren’t just writing code to fulfill some requirement on a note card, but you are actually creating a product that a business intends to use. Try to understand what that note card means to them as you transform the requirement into a feature.

In order to do the right thing, you have to know what the right thing is. Understanding the business behind your work is essential for any knowledge worker. This includes developers, testers, business analysts and technical writers. Without the vision of your work, you’re doing useless work. Remember the Product Principle from Weinberg’s Quality Software Management series: Anything not worth doing, is not worth doing right. Since you’re doing everything right, avoid doing anything not worth doing in first place. Of course, in order to make this decision, you need to know what your customer’s business is asking for.

Recognize your failures

Recognize your failures of the past so that you can move forward on a new level.

Taking the time for reflection is essential. Self-blindness about own failures does not help you grow. Therefore seek opportunities to realize your failures and learn from them. We all make errors at times. The aspect that makes us human, is the fact to learn from our mistakes.

Don’t be shy with your ideas

Throw your ideas out there, and then be the biggest critic of them. You only stand to gain when others see your ideas (unless youzz crazy).

Sharing your ideas is essential for the community to grow. Pay back what you get from the community by bringing in your own ideas. Of course, they might be subject to critics, but these critics will help you grow, learn from the mistakes you make, and contribute to your professional growing over time. If you’re shyly hiding your ideas in your mind, they’ll be gone when you’re gone. The other way round they may even survive.

Lessons always come at a cost

Stay positive, because if you are getting punished by your mistakes, remember that you also learning from your mistakes.

There is no such thing as a free lunch. At times you will wake up and see you have painted yourself into the corner. It’s essential to take course corrections at that time, though this might mean to switch your jobs. It’s a worthwhile lesson, but it has to come at a price. At times, you may have difficulty paying the price, though it’s the most sane thing to do. Remain positive about these changes.

Leadership, Software Craft

Ethics in Software projects

Leave a comment

Personally, I love to relate different aspects from other areas to my life as a software professional. Today the aunt of my wife celebrated a birthday, and I got the opportunity to overhear a discussion between my father-in-law and an uncle from my wife, who are both truck drivers. Since I read Secrets of a buccaneer-scholar, I became aware of combining different areas of my life together to learn something new.

Now, German laws demand high discipline from drivers on the road – especially truck drivers. There are given rest times for truck drivers, regulated by the local police officer. These laws evolved over time, to protect innocent truck drivers and other traffic participants from fatal injuries caused by drivers with too few sleep. There are other regulations that protect trucks from getting off-track, especially on the German Autobahn, where truck speeds of 100 km/h are usual – and cars drive with as much as double this speed.

So, working as a truck driver puts a certain challenge on you. You want to deliver your wares to the destination and hit back home. Your boss wants to deliver the wares to the promised date. Traffic jams, alternative routes, and other variables may put the predetermined schedule from your boss at stake. Today
I learned that it is common that the boss will then ask the drivers to skip their rest times.

But wait, what has this to do with software development? Well, if there are delayed deliveries from third-parties, shortcuts to requirements and/or design, among other variables, your project will be put on pressure. The predetermined project plan may become out of date. As the truck drivers’ boss, your project manager may ask to skip testing.

So, what is different in the truck driving part of this analogy is the fact that there is a police checking for too long driving periods. The German law then enforces penalties to the truck driver for giving in to the demand from their boss, so they may even lose their drivers license in extreme situations.

Seriously, I doubt that most projects would deliver untested software, if there was a project police in place, that would charge penalties from developers and even project managers for skipping testing. Sure, an overtired truck driver may deliver their goods on time in 90% of the cases, but if he just naps in front of the steering wheel once, and ends up in a massive traffic accident, the results will be dramatically fatal. The same may as well go for some software projects. However, avoid to give in the temptation to say “my project won’t cause fatal accidents, if I skip testing.”

If you didn’t get my main point, I would like to finally point you out to a fable about testing from Gerald M. Weinberg. His granddaughter Camille got the point from it at the age of four, can you get it, too?

Agile Testing, Software Craft, Testing

The Craft of Software Testing

1 Comment

The inaugural issue of the Agile Record magazine includes an article from myself about some thoughts on the craft of software testing. In it I describe my understanding about the craft and how testers may reach a level of professionalism where they know what they’re doing. Deliberate practice is one thing in that equation.

Looking through the magazine, I spotted great articles. Dawn Cannan co-authored with Lisa Crispin an article on being the worst and why it pays off, David Evans has an article on testability and considerations on whether to invest in it or not, Lior Friedman has an article on the agile view on quality, Marc Bless has an article on Scrum forced on an organization, etc. Before listing up all the contents here, go to the Agile Record page, subscribe (it’s free), and get your personal copy.

Software Craft, Testing

On the relevance of context

2 Comments

As software testers we use context to point out that not all practices may be used in any situation. This is one of the key principles of the context-driven school of testing. Robert Martin talks about particular practices in the professionals tool-belt that are used in a project based on the particular context of that project. Alistair Cockburn names the same concept Just-in-time methodology construction and defines a large amount of practices and principles to use in software development projects. For me there always seemed to be a pattern behind this concept and I decided to write it up for public discussion.

Lately, I read through the Quality Software Management series from Gerald M. Weinberg. In it, Weinberg discusses differences between the Routine organization and the Steering organization. The key difference between the two organizational cultures lies in following a prescribed way to handle a project and choosing among several techniques and practices based on the current situation. In a Routine organization there is one particular process defined and software projects shall follow this. Of course, project managers take care of following this one process. In the Steering culture there are many processes which may be followed. In a Steering culture the controller of the project chooses among several practices and knows when to adapt by taking the outputs of the previous project phases and feeding this knowledge in to the inputs of the next project phase. A controller of the project may consist of the designated project manager or the project team as a whole.

About two years back my wife amazed me with a similar lesson in a completely different area of life. For my birthday I got a jigsaw puzzle. My wife has over hundred puzzles in the house and she all finished them. When I got to know my wife, we spent several evenings together puzzling. During this period I had adapted a technique from her to get the puzzle started. By sorting out similar shapes and then combining them according to their particular shape-type, she was able to make steady progress with the jigsaws. Therefore I started by doing the same thing. Having finished the outer frame, I sorted the remaining pieces by their shape and started over.

After some hours puzzling, I realized that copying this strategy did not work out for my puzzle at hand. I did not make much progress and had become a bit fed up with it. After reflecting some minutes, I realized that I was stuck by the wrong strategy. The puzzle showed an image of penguins in an icy world. Therefore the pieces contained mostly black and white fragments of that picture. It was a lot easier to first partition the pieces according to the color rather than their shape. My wife applied the strategy by sorting out shapes with more colorful puzzle images, that helped her succeed there, but for the image at hand I had focused on the wrong strategy. After changing it I noticed that I could make much faster progress than before.

Of course, in the story above I had less experience with jigsaws than my wife had. Over the years she adapted several techniques for finishing up a jigsaw and based on the particular circumstances she choses among the several techniques she knows. When I started the jigsaw I had a vague understanding of one of her techniques and foolishly tried to apply it. Just by making myself aware of the situation when things did not turn out, I was able to try out a new approach to follow and add another technique to my repertoire. Similarly in software testing and software development we need to make ourselves aware of the particular situation in our project and reflect over the course of it. When we get aware about problems, we can help ourselves by choosing another technique or practice to follow for the next few weeks in order to improve the overall course. By continuously making ourselves aware of the situation and the context at hand, we can deal with changes circumstances and try out new things if we get lost.

Software Craft, Testing

Educational models in historic retrospection

2 Comments

Anna Baik took my recent blog posts and made a reflection on her swimming lessons in a blog post. In short, she stated that up until the age of 11 years she was not taught how to swim properly. Though her teacher insisted on some exam, she wasn’t able to take the test. In the end she did not learn swimming at school, but much later decided to learn how to swim with some advice from a friend. In retrospection I am going to introduce three different models for learning and education and discuss them in some depth.

Continue reading Educational models in historic retrospection →
Software Craft, Testing

Where is your context?

Leave a comment

Just finished reading through the rumble of the year between Matt Heusser and Alan Page on code metrics. Marlena Compton seems to have facilitated the session very well, since I haven’t heard of any casualties. One striking phrase from Alan Page led me to this blog entry:

In my world, code coverage measurement is another tool in the testers toolbox. We use different “tools” depending on what we’re investigating and where we want to guide our discovery process. We always need to use the right tool in the right context.

Thus far I haven’t thought consciously about context. Alan in the above mentioned quotation made me realize that there are multiple contexts to apply context to.

Continue reading Where is your context? →
Leadership, Software Craft, Testing

Patterns for Test Automation

Leave a comment

Robert C. Martin brought up a blog entry yesterday called The Polyglot Tester. He argues about the Behavior-driven development style of automated tests the table style encouraged from FIT, Slim, RobotFramework and others. While I’m not going to jump into the discussion which of the existing tools is better, worse or more suitable to do some job, here are some references to patterns for test automation, which I came across.

Continue reading Patterns for Test Automation →
Leadership, Software Craft, Testing

People Learning

2 Comments

Nearly everything in software involves some humans doing the job. Today I got a phone call:

Caller: Do you have some resources for me?
Me: Sorry, I don’t have resources for you here. Just people.

Reflecting back on my university years it’s interesting to notice, that we teach computers to learn just like humans, in order to replace humans by computers. But, while we’re doing so, we treat people like things. In addition most of the time people in the software get treated as resources, who can be sent to some course, get a degree or a certification, come back and know everything – inwards and outwards. Sure, this is how it works, of course. Maybe they will be inventing some injections in the near future. Then people – sorry – resources can be as productive all the time without the need to send them to trainings. Now THAT would be an improvement.

This is not how it’s going to work. Let me try to transport this concept to teaching swimming – one of my leisure activities I need in order to gain work-life balance. When setting up a swimming course like most of the projects I’ve been in to, this would look somehow like the following. In Germany the first certification is the “Seepferdchen” (tiny seahorse). By the time the kids know one to two techniques, are able to swim 25 meters (we use metrics here!) continuously and can jump from the edge of the pool right into the water. They can dive and fetch some rings from 1.2 meters depth (metrics!). That’s it.

Now, this is the basic certification a swimming student needs. By then he has the knowledge how to swim through the pool. Ok, let’s put her on a project – a swimming contest. She made her grade with an A, so we better have her sent to the national swimming competition. Of course she knows how to train for the event. Ready, steady go…. What do you think will happen?

Right, when battling the 100 meters against Michael Phelps or Alexander Poppov or Mark Spitz your kid will drown. Why? Because it lacks practice. It does not know how to swim properly with the resistance from the water. The experience of the water pressure is known to her, but not how to use it for her advantage. In addition the muscles has not been built properly to beat with world class swimmers like the ones I mentioned.

There is a pattern we observe each holiday season. Parents sent their kids to our swimming course, because they are going for two weeks to the sea and the kids need to be able to swim by then. Of course, six weeks are enough for anyone to learn to swim. After telling the parents that we have a waiting list for new kids, they take it disappointed to have to wait for a free place. In the end when the kid gets their certification (remember the seahorse), they take the kid with them for their holidays. Why is this dangerous? The kid has just practiced in a safe environment without waves and without streams. The kid knows how to hold their face above the water for some time, but without having the right condition to do it over time when the waves take them out far to the sea. Basically all that certification says, that the kid is able to do basic swimming without saying anything about the abilities.

I hope I raised the point for practicing far enough by now. In order to survive the waves of the software development projects to come, you need to practice your abilities. You need to train and have your programming and testing muscles being built up right in shape in order to survive the streams of the tar pit (see Brooks’ The Mythical Man Month) of software development projects.

But keep in mind that there is no pattern or schedule for people learning. In fact some kids take more than a year to learn enough to get the seahorse certification, others may be able to do the practices for it in just ten weeks. There is no way to have them scheduled on a certain date, because each kid has their own pre-requisite of moving behavior and familarity with water. Compare two kids. The first one has taken baby-swimming courses right after birth and is very comfortable with the element. The other one has nearly survived a fall into the local pond at age of three. The first one is likely to take a shorter period of time for learning how to swim. The second is more likely to have fears against the element that need to be removed before the kid can get trained on the techniques. So, it’s likely to take a longer period. My considerations are not guarantee, though. (On another note I would be happy if I got told about certain fears before starting to work with the kids sometimes.)

I hope it’s obvious to see the similarity to people learning how to test software or how to develop software. People differ in learning styles and learning speeds, but people learn. The difference is to get the hook on the past experiences of the people good enough for them to take the step beyond that gap to the new models you’re providing. Therefore a good learning approach is to settle for multiple models of your teachings in order to get as many people as possible and make them able to refer to your model as well.

Leadership, Software Craft, Testing

Multiple facets

1 Comment

As a swimming trainer I was taught that I reach some of my students with some exercises, some of my students with some tactile impulses while some others need to be taught the model by showing them my movements. Keeping in mind that “correct” is an interpretation from some human, I don’t think there is one and only one correct path to teach anyone anything. People vary in their ways of getting the hook on something.

That said I don’t believe in the single solution of a training model. I believe that we need multiple ways in our toolset to teach people what we’re actually doing. People perceive some of the lessons we teach them by one or more of the following:

  • formal training classes
  • reading a book
  • failure on the job
  • failure in some save environment like a training session
  • watching an experienced professional doing some work
  • (positive) on-the-job experience

Though we don’t make much use of tactile experiences in the software world as I may need as a swimming trainer, there are multiple facets of learning. Based on cultural aspects and diverse background from people there is multiple responsiveness to certain aspect on software development education. This also holds from my perspective for software testers – and I believe for nearly all jobs.

Over the course of this year I got to learn about Coding Dojos. The arrangement there is to have people from the audience brought in to some time-boxed hands-on experience in a save environment. The second aspect is watching two experienced developers developing code. This arrangement sets up people for various learning facets. The more ways we try to set up the learning, the broader our learning audience will be.

The interesting part here is that people can gain experience while they are work. They can be taught what they may need tomorrow. Since the learning is based on a broad set of tools enabling learning, we make sure to include more people – more people that may need more diverse techniques for learning. The concept behind Coding Dojos is very impressive, and it works.

The question that struck me nearly all year is, “May we use this idea also for training testers?” For quite some time I knew there is some way, but I didn’t know my model about. Then something happened that made it very clear for me. More on this in the next blog entry in this series on learning and education.

Software Craft, Testing

On Education

5 Comments

Last Friday I visited my old university where I studied up until just four years from now. The place where I learned how to learn. It was amazing how little changed beside the fact that students nowadays get charged a whole lot more money for their education. In Germany currently there is a rough discussion about these fees and that the universities do not take care for the educational side properly. The graduation celebration I visited last Friday was accompanied with a talk from a previous mentor of mine. He had some data on how education had changed over the last decade and made a comparison between the old Diplom courses and the new Bachelor and Master system. Reflecting over the past years and that talk, I came to the realization that there seems to be a gap in our industry currently.

What did I see or hear that leads me to this conclusion? Reflecting back four years from now I knew nothing about software testing. Over the last years of my study I concentrated on pattern recognition, like face-detection in images, and my diploma thesis handled about hand gesture detection in human-robot interaction scenarios. Back in April 2006 I joined a team of great testers and needed to learn software testing. Thus far I had not participated in a course on software testing. The team I was working in was doing a whole bunch of software test automation using shell-scripts. Over the course of the next few years I did learn how to teach myself what software testing is about. I learned that software test automation is software development, I learned that exploratory and sapient tests are very worth the effort, when accompanied with the right organizational methods, and I learned a whole bunch about Craftsmanship and Cooperative learning sessions.

In general I would conclude that I learned almost eighty percent of the stuff I need on a daily basis right after leaving the university, while the material I learned in university is not that relevant for me any more. As a software tester I don’t need to know how a wrenches for robot hand motorics work, since I don’t need them. Multi-layer perceptrons are not an option for me. Learning algorithms like AdaBoost and online and offline algorithms are not needed in order to test software. Well, I wouldn’t claim that the rough six years I spend at the university were wasted, but I feel that I dd not learn the right things there.

Recently I noticed that there seem to be others who feel just like me. The Software Craftsmanship conducts coding dojos and programming katas to teach the apprentices what the universities are not teaching them. Design Principles like SOLID and Design Patterns are taught on a on-the-job training between Journeyman and Apprentices. For software testers there are similar things happening, i.e. James Bach and Michael Bolton created a Rapid Software Testing class, Cem Kaner has also great courses. Yet, besides Cem Kaner and other distinct persons we do not seem to have reached the universities with our efforts. When I took a course named “Software Praktikum” back in the year 2000, people were talking about test-driven development and that new movement called eXtreme Programming, but no one really taught us something about it.

When I took a look on the course material nowadays I found out that the situation had been improved over the last few years. Nowadays students get offered test-driven development courses, some Design Patterns and maybe some Refactoring. Unfortunately I did not run across a testing course at my university.

Therefore I concluded that I would like to do something on this as part of a New Year’s resolution. Personally I want to help people understand software testing, help them grow into the craft and hopefully get a better tester than I am. There are a lot of movements currently going on, and I think based on my past I can be a contribution to these movements. This is all I want to say for now. If I made you curious about more, you may want to subscribe to my feed, as I will be digging deeper here shortly.