Proud to be published again at OpenSource.com

A very topical subject suggested by a co-worker and former/future boss - the need to manage a combination of standardization and innovation:

https://opensource.com/open-organization/20/2/standardization-versus-innovation

First Posts at the Red Hat Developer Blog!

Very happy to finish off the year with two new posts published at the Red Hat Developer blog!

https://developers.redhat.com/blog/2019/12/19/introducing-the-service-binding-operator

https://developers.redhat.com/blog/2019/12/20/service-binding-operator-the-operator-in-action

Another post at OpenSource.com!

The second (and final) installment in the series of posts regarding influence in the open source world was just published!

https://opensource.com/open-organization/19/10/how-to-influence-open-community

First post at Opensource.com!

Very happy to announce that my first post at Opensource.com was just published!

https://opensource.com/open-organization/19/10/gaining-influence-open-community

This is the first installment of a 2-part series!

Midsummer Thoughts on the Fun of Coding, Obvious Secrets, and Whether Plumbers Plumb on Vacation

A recent documentary shown on american television (https://www.golf-films.com/hogan) told the story of the life of Ben Hogan, the greatest golfer of the 1950’s. Hogan is a fascinating person, not only for his success as a professional athlete, but his overcoming personal tragedy. His father committed suicide when he was a child. Years later, as an adult, when he reached the pinnacle of his sport, he was nearly killed in a head-on collision between the car he was driving and a bus. After multiple surgeries and months of recovery, he was once again able to become the top athlete in the world for his sport. He became so proficient, in fact, that he was rumored to have found “the secret.” 

Every athlete searches for the secret to better performance, but in reality, “the secret” usually comes down to a combination of talent, hard work, and perseverance. In Hogan’s case, it was definitely a combination of the second and third of these factors. To a great degree, he invented modern practice where repetition in practice was the key to success performance under pressure. It has been an obsession lasting decades to try to discover Hogan’s secret. The answer may have been obvious. If he had a true secret, it was hard work coupled with the fact that he actually enjoyed practice. It was never work or drudgery to him. For him, practice was actually fun.

But, what does this have to do with software engineering? Fast forward to this week. 

We had taken the family to the beach for a week of vacation. After returning from a day at the beach, everyone in the family was relaxing their own way. My wife poured herself a glass of white wine and became engrossed in FaceBook.Grandma tuned the TV to the Golf Channel and complained about the beach traffic to anyone who would listen.The kids tortured each other over a game of ping-pong And me? I put my feet up and was unwinding by downloading an open source project that I had just discovered on github. Later on, my daughter remarked to me, in her usual subtle manner, “Geesh dad, you’re always on the computer. Don’t you ever want a break? Do you think that plumbers do plumbing when they are on  vacation?” She does have a point. For a lot of people after working a full day, the last thing that they want to do is to look at or work on anything job related in the evening, especially when they are on  vacation. I tend to doubt that very many plumbers do a lot of plumbing when they are on vacation. 

But, software engineers are different.

What is is about software and software engineering that makes us always wanting more? One reason may be that rapid changes in technology are interesting and frequently exciting. Another reason might be that given the rapid rate of change it’s important for your career to stay current with the latest  developments. 

These are all valid reasons, but I think that the "secret" for us, just as it was for Hogan and his practicing, is obvious, that we actually enjoy reading and writing code. 

In other words, for us, it’s fun!

Part of the fun comes from the nature of software itself. When you're working with physical media such as with steel, or concrete, or beach sand, the limitations of what you can do are based on physical limitations of that media and the physical environment. In contrast, with software, you can face limitations of memory or CPU speed or environment, but you are primarily only limited by your imagination. This is what makes software engineering so rewarding, and so much fun. You are basically building virtual structures out of ideas. And, unlike physical media, you can easily tear down, redesign, and rebuild structures in software. 

Wishing everyone a fun end of the summer!

Divided by (the lack of) a Common Language?

”Why are you bothering with tests that don’t work?”

I remember the incident distinctly, even though it took place several years ago at a company that no longer exists, while my team was building and testing a long forgotten product. I was reviewing a software test plan with a development team colleague as I wanted his input on the risks associated with a new feature. I described the functional tests that wanted to build for the feature, and then mentioned that we would in parallel be updating the product’s non-functional tests (such as performance and security tests) to take into account the new operation of the new feature. He looked confused and asked me,”Why are you bothering with tests that don’t work?” His question caught me off guard and when I asked him to explain, he said, “You’re talking about tests that won’t function. Why are you wasting time on those tests? They’re broken, right?”

At that point, I thought of George Bernard Shaw’s famous quote about the British and Americans being two peoples divided by a common language. In this case, however, the problem was two groups of people being divided by the lack of a common language. That being, the language of software testing.

Historically, Development and QE teams have been kept separate. The separation was based on the belief that the only way to have effective and unbiased testing of a product was through having an independent testing team. One of the rationales for this separation is that testing always includes an element of “creative destruction” and that is difficult for people to act in a destructive manner toward their own work.

In an agile development model, this artificial separation is done away with. The walls that divided development and test engineers are torn away broken and they work together as members of the same team, where the quality of the product created is owned by every member of the team. The transition to this model from a traditional waterfall development model can, however, be difficult. The problem is that people without a QE/test background will be asked to build and run tests when they may lack hands in experience in test development beyond building unit tests. The “test guys” (that is, the QE/test engineers) can help by providing guidance and coaching, but but that coaching can difficult because people new to testing will not have a frame of reference to build upon.

A Shared Language - And Two “Good Reads” for Anyone Building Software Tests

When you work in a technical field it’s easy to become totally absorbed in the technology and forget the importance of human communication and community. What makes a community? Shared values, shared goals, shared experiences, shared literature, and a shared language for software testing.

It’s winter here in Boston, which makes it a great time to sit down by the fire, or at least a video of a fire, and do some reading. There are a couple of resources that anyone new to testing should read:

The year 2019, marks the 40th anniversary of the original release of Glenford Myers’ book, The Art of Software Testing. It’s still my favorite software testing book. In this little book, Myers provides a practical, and very readable description of methodologies for software test design. Equivalence partitioning, boundary value analysis, it’s all there in The Art of Software Testing.

In its syllabus and glossary, just updated in 2018, the International Software Testing Qualifications Board (ISTQB, https://www.istqb.org) provides a detailed and systematic definition of software testing. Founded in 2002, the ISTQB has established standards and certifications for software testers. In their glossary and syllabus, the ISTQB painstakingly describes how to design, organize, execute, and report on the results of software testing.

Building effective software tests are not just for “the test guys” anymore. In an agile model, we all own and contribute to and execute tests to improve product quality. Doing some basic research by reading The Art of Software Testing and the ISTQB syllabus and glossary would make for a very useful New Years resolution for anyone wanting to learn learn the language of software testing and to create better tests. Happy 2019!

Management tip - When the Pizza is Free, Answer the Phone

It all began with free pizza.


Public Domain, https://commons.wikimedia.org/w/index.php?curid=79505

Many jobs ago, when I was working for a company that coincidentally no longer exists, there was a monthly event that no one looked forward to; the monthly managers’ meeting.

My fellow managers were, as individuals, extremely pleasant and competent people, but when they got together, group paralysis seemed to set in as they became collectively incapable, or even afraid, of taking independent action.

I remember one meeting especially well as it taught me a valuable management and leadership lesson. It all involved free pizza. In an effort to improve both morale and attendance, it was decided that the monthly meetings would be scheduled during everyone’s lunch hour, and that a free pizza lunch would be provided.

The meeting started promptly at noon, and soon settled into a familiar pattern of discussing, delaying, denying, and deferring actions to be taken.

And then, the telephone in the conference room rang.

The conversation stopped. Everyone stared at the telephone as it continued to ring. What could this mean? Why would someone place a telephone call into a conference room? Were we being watched? The phone continued to ring. Everyone stared at the phone, trying to will the ringing to stop.

After a few rings, I answered the phone. “It’s the front desk. The pizza is here.” Instantly, the tension was broken. Everyone started to breathe again.

But, after a few seconds, everyone froze again. Glances of uncertainty were exchanged. Everyone in the room shared the same thought, “What should we do now?” After a few more seconds of deafening silence, I stood up and addressed the team, as they sat frozen in their chairs and said, “I’ll go downstairs and get the pizza.”

OK, I may be exaggerating for dramatic effect, but I really did see this happen. It’s easy to dismiss this silly little story as a silly little story, but I think that there’s more to it. Individuals, small groups, and large institutions often create their own inertia. It’s the responsibility of team leaders and managers to recognize when forward progress is stalled and change the team’s inertia by removing obstacles. This may require shifting resources from one task to another, or it may require adjusting the relative priorities of task assignments, or it may require simply answering the phone and picking up free pizzas.