This has been my testing blog's home for many years. As things have grown, they have also changed.
One change is my new website, which is the new home for my blog going forward.
You can find it here.
This is the fourth piece looking at life as a contractor, when that isn't your
first choice of gig. The first part is here. The second can be found here.
The third is here. Please continue with me on this journey,
The question of "professional responsibility" or "responsibility" in general, is one that is hard to describe in sweeping terms. Instead, I look at it in very small, granular ideas. These grains of ideas might add up to something bigger for you. .
First, when working, work. You can't stay 100% focused all the time. That is obvious to anyone who has ever worked in software. There are ways to do redirection which can help you maintain focus. A brisk walk to get some tea or coffee or up and down the hallway a moment.
Working from home? A short walk away from your work area and back might do the trick. Come back ready to go.
If the client wants 10 things all at once, don't promise what cannot be done. Have the conversation around what can be done, by what point, when combined with other accountabilities for the organization and the team.
Work to define what is really the most important of these. Then the next most important, and so on. Of course, the priorities are likely to change. The availability of resources can impact what can be worked on. Other needs might arise which need to be addressed.
Also note the time and effort it took to handle the changes and how these impacted your ability to deliver on the 10 things the client originally said they wanted.
Communicate with them. Let them know that working on issue X will impact your ability to deliver Item 1 on time. Is that what they want or should you focus on Item 1 and work on issue X as a secondary task?
This does not mean stop and do nothing until you get direction. Work on understanding both of them. This understanding will help you structure your work so even if you are blocked on one thing, you will not be blocked on everything.
This is pretty normal. It is not significantly different from working as an employee, right? One big difference is being able to account for what you are doing. You need to be able to show what you are working on and maximizing what you can produce. Another big difference is a basic rule, no "extra work" is done unless you can bill for it. Do not work any hours you cannot report and bill for. You are not an employee. You are an hourly worker, paid to do specific tasks, by the hour.
That is why you need to be able to show what you are doing and working on. You need to show that you can make progress on important tasks even when "blocked" on the top priority items.
Yes, there is a cost to switch back and forth between tasks. I don't recommend it unless there is a clear reason to do so. If you are waiting for a response to a question that needs an answer before you can proceed, that might be a reasonable thing to do then.
When it comes to "questions," odds are you'll be asking a lot of them when you start a new engagement (contractor-speak for 'gig'.) Be open to the responses. Also, look for how the answer is presented, not just what the answer "is."
Was there a sigh or a pause before the answer? Was there some hesitation as if selecting the "right " words? These might point to areas the other person is concerned about or has some other insecurity. It might be an opportunity to offer help.
Yes, I get the "don't impose help" basic rule. This is not really "imposing help." Sometimes a little empathy and a leading question can go a long way
"You seem a little unsure about answering that. It's OK. Maybe we can come back to it. Or, is there something you'd like to talk about now?"
Coming in from the outside, contractors can bring a fresh set of eyes to situations and problems in the organization. It might be that your experience is different from the experience of others you are working with. If most of the teams have been there a long time this is likely. If many are in their first one or two jobs in software, it is a certainty.
You can bring a perspective they do not have which can help them.
It may not be your "job." It is one way you can help them and demonstrate how you can contribute to the project being a success. It is a small amount of effort to hear their questions and give suggestions based on your experience and understanding of their situation.
By building a relationship based on trust, you help them do their jobs better. You help address the questions they have and present them in ways they could not present them.
Building trust is the most obvious and easiest way there is to bring value to your clients. When the people you work with come to you asking for suggestions or advice, it often means that they and the rest of the team have never encountered the situation before and need guidance. It is highly probable their leadership has likewise not encountered the situation. If they had, it seems unlikely the team would be coming to you if their leadership had already given them advice or direction.
There is one more really important factor to consider.
Always be honest. As tempting as it is to say what the client wants to hear, if that is not true or accurate, don't say it. Be forthright. If something they want to do seems a bad idea, say so. Tell them it is a bad idea, and why. Offer a suggestion or an alternative direction.
If there are multiple "outside" agencies involved, be aware of their motives. Are they operating in a boiler-plate approach? Where one-size-fits-all? Are are they working to meet and fill the unique needs of THIS client? If there is a large team from one or more organizations, are they operating in a way that makes sense?
If their performance measures for their teams and individuals are not in alignment, tread carefully. Watch to observe behaviors of individual contributors and how they differ from the client's employees and those of the other agencies.
In this thing, one key point to keep in mind: going with the flow from the predominant agency may not be in the best interests of your client.
Always act with your client's best interests in mind. Be willing to explain your perspective and reasons for the differences. Let them decide, then act accordingly.
great challenge for most people appears to be not having a tangible
idea of what success is, or looks like. For some, it is a large income
with a fancy title, the ability to afford a really nice car and home.
The ability to join the "better sorts" of society.
That might work for some. I find the idea of success to be illusory. What others bestow on you, they can also take away. What you can do for yourself, your family and friends is more real. I find "success" to be paired with "happiness."
There is a quote often attributed to Mary Kay Ash, the founder of the cosmetics company which bears her name, Mary Kay. It runs:
"Happiness is having something that you love to do, someone to
love, and something to look forward to."
For software professionals, I believe this translates to something like, "interesting work solving interesting problems, someone or something to care about other than yourself and something that can be achieved to reward yourself with."
I cannot define what success looks like for you or anyone else. I cannot tell you what motivates you. I can tell you my thoughts on the idea of success no matter if it is as an employee, contractor or consultant. Maybe there will be something there to help you find your idea of success. Maybe that will help you find what motivates you to reach it.
Trying to define "success" for anyone other than yourself is nearly as pointless as trying to find what "motivates" another person. Both, no matter what you may have learned in school or heard from famous and infamous pundits. Both are internal. Both could be absolutely true for one person and absolutely false for another.
No single person can define what success looks like for another. No single person can define what might motivate another. The challenge is finding and defining what success looks like for us. We ourselves can figure out what motivates us.
The myriad ideas around "success" shift and change over time. For many, in the end, the idea of success is to be happy, or at the least, content. If we have a "job" with a title and a large paycheck, oftentimes those are bestowed on us. This means they can be taken from us.
I cannot tell you what success looks like, for you. I can tell you how I view success. Maybe that will help you in your thinking about success.
I cannot tell you what success looks like, for you. I can tell you how I view success. Maybe that will help you in your thinking about success. It doesn’t matter if it is as a “contractor” or “consultant” or an “employee.”
Know why you are there.
If there are obvious problem areas it is tempting to jump in and say "Let's fix this!" I might gently suggest not doing that. Gerry Weinberg in The Secrets of Consulting warned against "imposing help." It doesn't matter the situation. If they are not ready to ask for help to change, or fix, a problem, then let it be.
No matter how many areas where there are improvements that can be made, focus on the reason why you were brought in. Understand the rules in place and how people work. Understand the problems they face and recognize it is possible there are perfectly reasonable explanations for why they are doing something in a way you find suboptimal. Learn the energy and observe.
Oh, and do what your contract says to do. If that is "write code" then by all means write code. If that says "test code" then test the code. This becomes the biggest challenge and the largest responsibility area for you.
I've seen several people come in and suggest things that might help an organization. Yet those things were not part of why they were brought in. Don't fall into the trap of "this is more important" than the testing or development work. It may be more fun for you, but until you are asked to propose changes to those other things, don't.
Do what your contract says. Do it to the best of your ability. Demonstrate success and let them see what you can do. When the contract manager or their boss express frustration with a situation, ask if they would like help with that.
Until you are directed otherwise, your primary task and purpose is what your contract says. This should always be remembered.
Know when you are there.
Doing what we do, most of us are salaried employees. There is an expectation we will "get the job done. " If there is any chance we cannot deliver the work because of problems we encounter, we need to communicate that clearly and let our team and management know we are having problems.
If the problem is "there isn't enough time to do this" the response is usually something like "It needs to get done on time."
In my youth, I had no issues working massive hours of overtime to "get the job done" and "deliver" what was needed when it was needed. I remember one position where for a three month stretch where I was working an average of 70 to 80 hours a week. I no longer recommend that.
When you are salaried and you hit "crunch mode" then most shops expect something like an "all out effort." While three months is a crazy long time, when you are working under contract, the rules are different.
If the "expectations" are not different, check the terms of the contract.
In your contract there will be some very specific things. There will be rules for you to follow and adhere to. (Many of these likely resulted from stories that might best be related over beverages after hours.) There will be expectations listed:
There will be an outline of what work is to be done. This may be fairly exact, or it may be broadly phrased. Any discussions had before the offer being extended would likely have given a clue what the terms meant.
There also will be a rate to be paid in exchange for that work.
Much of the time, this will be presented as an hourly rate and how to report time and file an invoice for the time. Usually, there will be a fairly explicit instruction that the work is to be 40 hours (or some other number) per week.
There it is. The magic limit. This is usually the most you can report and invoice for in a single week.If you work more than 40 hours can you report and invoice for it? Maybe. It depends on the terms of the contract. I have usually seen a requirement that anything over 40 hours needs prior approval from the client.
And there's the rule. That right there. If you are not approved to work over that limit, don't.
You are being paid a specific rate per hour for doing specific work. Working more than the contracted time per week (normally 40 hours in the US) that might be OK. If you can invoice for them. If you cannot get paid for doing the work, don't. Explain it to the people who want more time - gently.
Sometimes, often, any work done OVER 40 hours a week is at a higher rate. If hours 1 through 40 pays you at, say, $40 an hour. Hour 41 and over might well be something like $50 an hour.
The placement firm you are contracted through likely also sees a bump in rate. If you get paid $40 an hour, normally, they are likely billing the client $60 or $70 an hour (or more.) That is, after all, how they make money from getting you the gig. It also may cover "their portion"of the benefit costs if you selected any benefits.
For them, you working any overtime means they get more money, too. Your $50 an hour for work over 40 hours a week might result in them billing $80 or $100 an hour. If you work 5 hours of "overtime" and report it and invoice for it, that will cost the client perhaps $500 in this example. Likely more.
Most of the contracts I have worked, there was a clause that no overtime would be paid if not agreed to "in advance" by both parties. The "in advance" part is a little grey, if not murky. In short, you can't bill them for extra time worked if they don't agree to pay you before you work it.
Most clients are thrilled to have people work "extra." They just don't want to "pay extra" for it. Short version - if it takes more time to get the work done than is contracted for, make sure the client will pay the invoice. If they are not willing to pay the invoice, don't work it. When you hit 40 hours for the week, shutdown.
Doing "extra" for them might help them in the short term. It certainly does not help you. It also does not help the agency you are contracted through.
You owe it to yourself to make sure you get paid for every hour worked.
But, what about "professional responsibility?" Excellent question. That will be covered in the fourth part of this journey.
This is the second piece looking at life as a contractor, when that
isn't your first choice of gig. The first part is here.
Please continue with me on this journey,
Loads of people work as contractors and really like it. They like it a lot. Most of these chose to become a contractor at some point. Some have become full time employees of contracting firms. Of course, many of those firms prefer to be described as "consulting services." Whatever. There is a difference. I won't go on a rant about it here. Maybe later.
Having said that, part of the reason companies bring in contractors for software work is simple. They can be brought in for a specific purpose or task. They do the task. Then they go away - with money in their pocket.
They (well, me included when working on a contract assignment, so "We") are software mercenaries. Most folks don't like that description. I prefer "privateer." We get hired to do a specific task. We do it. We leave and go to the next engagement. Sometimes they want us to stay and do another specific task. Then the contract might get renegotiated. Or not.
There is one thing I have not said about contractors, software mercenaries or privateers. If my contract is for a specific task - that is the task I do. I am not acting as a consultant. My primary purpose there is not to help them improve and make their world better.
Sometimes, if the contract is to be a ScrumMaster or "Agile Facilitator," that means my purpose is to act as a ScrumMaster and teach the team, or teams, about things "Agile" - or at least, Scrum. These contracts might be of a short duration, or fairly lengthy. They might get renewed - or not. Still, the fact remains - when the task is done, in this case, the teams are up and running and able to be self-sufficient so they don't NEED a ScrumMaster, I leave.
I tell teams I'm a bit like Nanny McPhee - "When you need me, you don't want me. When you want me, you don't need me." That is still a contract, although it does trend a bit to "consultant."
The difference is often rather mechanical.
What does that mean?
An organization brings in someone for a specific purpose. For example, a person is on medical leave for a few months and the company needs someone to do the basic day-to-day tasks of the job so the wheels keep turning. That is a pretty typical temporary "contract" position. Fixed period and very specific scope.
Another company is getting bogged down in a software project and needs help getting it written and tested so it can be delivered on time. Maybe the same company needs a new automation framework to be developed to be able to more efficiently conduct testing for the same project. These are both typical "contract" scenarios. You have a set purpose, mission and expected end date.
The example from earlier, working as a ScrumMaster to get a team up and running within a Scrum framework. The task is to get the team to be working as a self-organized team, executing and delivering in a period of time. If they are reasonably well functioning to begin with, this can be very successful. If they are well functioning, this task will likely be impossible in a 6 or even 12 month time period. (This is one of the challenges using a fixed-date contract for a role like this.)
The contracts for these positions will usually define specific skills and abilities for the person filling the role, as well as expectations of what is needed. These will get circulated with various firms who will scramble to fill the roles - often presenting a slew of candidates in a short period of time.
Will there be challenges? Sure. Of course there will. Automation frameworks need to be weighed and balanced between several factors. Then designing the framework, and so forth. Completing these tasks takes a fair amount of effort and can sometimes be a challenge. In the end, however, the framework is fully functional and people from the client company can use it without considering how the framework was built.
In each of these, the important thing to the client is not that they understand how the thing was done, but that it was done. Because it was done, they can carry on with what they need to do.
It is likely you have encountered this before and have had contractors do work for you. Maybe not the huge, massive work like building custom designed house. More likely, bringing your car to an automotive garage for repairs or maintenance. Calling a plumber or electrician to fix a problem in your home is the same arrangement.
They are doing work for you - a specific task. They contracted to repair your vehicle or your plumbing for a given rate, normally within a given time frame. It is very mechanical.
I know a fair number of people who do contract work and brand themselves as "Contracting Consultants." The challenge is, that is inaccurate for most of them. I know. People will point at specific things and say "See? I'm a consultant! Not a mere contractor!" Fine. Sure. One can use nearly any word imaginable to describe themselves.
When a consultant is brought in, the problems which need to be addressed are more open-ended and less well defined. There is a change needed, but what that change might be is often a vague idea in the minds of the client. It also might be completely inappropriate for what they say they want to address or achieve.
How is that different from contract work? I look at it like this.
A contractor will fix your car for you. A consultant will teach you about modes of transportation, find some that are most appropriate for your needs and then guide your decision making. They may also teach you how to repair your car yourself so you don't need to bring them in for automotive problems again.
They will help you become capable of determining what needs to be done then doing the work yourself.
A good consultant will lay the groundwork for future work, by satisfying their client's needs in a way that the client will turn to them for guidance and help in areas other than what they are brought in to address.
A contractor will help you "transition" your team to some form of "Agile" as you believe it is needed. A consultant will have the hard conversations looking at why you want to “do Agile.” They will help you determine if there is a reason to "do Agile" other than that is what everyone else is doing.
A charlatan is someone who comes in with a prepackaged solution branded with their company logo to fix your problems without knowing what those problems are. They excel at selling clients a bill of goods. All the while, they will tell you that this “solution” is right for you and they can help you implement it and get all the awesome goodness of “Agile.”
The world of working in software changed with the COVID-19/Coronavirus pandemic. Loads of people were "made redundant" or "laid-off" or simply fired. Many are having a hard time getting in with their "ideal" gig. Some, some of them being people I know, have simply given up and are doing other things "for now." This post marks the first of a series of posts on my experience working as a contractor - not a consultant. There are similarities but they are decided not the same thing. I will address the differences an up-coming post.
The last six weeks or so, I've had conversations with several former colleagues. These were people I worked with some time ago. A couple were recent, more were several engagements and a few jobs ago. All had been "let go" recently, either the result of the COVID-19 economic downturn, or some organizational restructuring or some other reason. I asked each of them the same basic question...
They gave answers that could be summed up as "Just like the last one I had." This seemed reasonable, given they had been in their respective roles for some time. It was where they felt comfortable. Each of them added one more thing - the same thing: "I'm not interested in contract work. I want to be a full time employee."
I asked why that was such a hard requirement. The answers could be summed up in a few points.
Each wanted to have some sense of stability in their position. Some had left their last role after a couple of years. A couple had been with their company for 5 to 7 years. One had been there 14 years. "Stability" has a level of attraction which makes sense.
2. Medical Insurance/Benefits
For folks in the US, this is huge. The certainty of quality health care is a massive attraction in a society where most people's health care insurance is provided, or significantly underwritten, by their employer. This might not make much sense to people outside the US, but the simple fact is, for many Americans, if they lose their job they also lose their medical and health coverage. It might not be immediate. It might be a couple of weeks or a month. But sometime soon, those will end.
3. Sense of Belonging
This is the easiest one for everyone to understand. Most people, in my experience, want to believe, or feel, they are part of something bigger than them and bigger than a paycheck. The feeling of being an "outsider" can be hard, particularly in a society where mobility has transported family connections across the continent or the globe. When your identity gets defined by what you do and where you do it, when that ends, what now is your sense of identity?
These are all reasonable expectations. At least, they would have been reasonable 20 years ago. The might have been reasonable 10 years ago. For the situation we are in now? I'm not sure how reasonable it is.
Over the last 15 or 20 years, I've seen a shift in practices for a fair number of companies. Typically, they had "just enough" software folks to do what they needed to do. They would be able to make tweaks to the existing systems and modifications to what was going on. There was a time when building a website or mobile app would generate a fair amount of excitement among the software folks working there.
Before then moving away from a mainframe and shifting to a client/server environment generated a fair amount of excitement. I remember one place I worked where folks were excited about the shift to the "new language" of COBOL. They were shifting from PL/1.
Excitement isn't enough to make things happen, unfortunately. Whatever illusions I had about working in software at a single company for my entire career ended long ago. (To be precise, 1985.) I knew I would never work for a company where I'd be presented a gold watch as my grandfather was when he retired.
For some people, working at a single company for most, if not their entire career, is normal and wonderful. It is very comfortable. And then it becomes not comfortable.
Stability is a Myth
If you are in the States, and live and work in an "at will" State, I suspect you have less safety and security than you think you do. You can be let go at any time, with or without a reason. Sure, you can collect unemployment for a while, but that is often far, far less than you might think, if you have never been on unemployment before.
If you, like some of my colleagues, were "let go" because of the downturn from the pandemic, you likely have come to the same realization. Companies will do what they need to do for themselves or their stockholders. A shock to the financial statements might be one thing. There might be warning signs. There might not.
In the US, if you are the primary source of insurance coverage for you and your family, the Affordable Care Act (ACA) can help, maybe. You'll need to find some form of insurance to at least cover you for a while, until you "get back on your feet."
The first time I took on a contract role, I went in well aware of the challenges. I was working as a straight C2C/1099/Self-employed contract person. I was responsible for buying my own health insurance, paying estimated taxes quarterly and paying "full book" for taxes where normally the employer pays half and the employee pays half. It was complex and a challenge in a lot of ways.
Unlike many today, I went into that well aware of what I was getting into and it was my choice.
Loads of companies, by no means all, are no longer willing to bring on "independents." They want someone "affiliated" with a company they trust, have worked with before, or at the very least, have heard of.
The result is many ads are being posted for positions by those firms (placement, contract, whatever) to meet their client needs and expectations. These come in several shapes, sizes and flavors. I'll talk about them in a bit.
The biggest change, and most consistent, is how you are working. Instead of being an employee of the client, you may likely be a temporary employee of the firm that placed the notice. The "temporary" part means you are an employee for the duration of the contract. The employee part is they will handle payroll tax withholding. They may also offer some form of benefit package you can choose to participate in.
If you DO choose to participate in the benefits, it may (and almost certainly will) limit what your billable rate will be. Ask. Ask what the costs are to participate in their "benefit program." Then compare that program with what you can find on the market. Your best bet might be to take their program, or it might be something on the open market.
What about stability and job security? Excellent question. There are a couple of ideas in my head around that idea. First, contracts have a fixed duration. They might be 3, 6, maybe months or longer. Usually they can be extended or renewed.
Much of the time, there are clauses that allows them to cancel the contract. Most of the time, they can cancel at any time for any reason.
If you work in an "at will" state as an employee, this is exactly the same thing that can happen to you. You can be "let go" at any time for any reason. The difference in these two, is an employee may be able to file a claim for unemployment support, depending on things like what state the employee lives in and what reason, if any, the employer gives for you being let go.
Belonging and Community
This is a huge challenge. It will continue to be a challenge no matter if you are an "employee" at a company or a contract worker doing work FOR a company. Many, perhaps most, companies that make software have people working "remote" because of the COVID-19 pandemic. This trend will continue for some time, I suspect. (Last I heard, Uber software folks are not expecting to return to their offices until June of 2021 - at the earliest.)
When you are physically distant, as well as not really being part of the club, there are challenges in keeping and maintaining that sense of purpose and team.
Virtual meetings and "happy hours" don't relieve the strain and in some ways make it harder. These are part of what I see as a response to the pandemic-forced remote work - and not unique to contract employees.
In short, no one has a strong sense of belonging unless they make it for themselves.
There is one consideration I have not mentioned. For a lot of people, even if there was some form of severance package, that money won't last for ever. Unemployment benefits vary by State. It almost never comes close to what your pay was before "the change in circumstance."
The adage about how it is better to be employed and looking than to not be employed and looking still holds true. I'd like to think folks are compassionate these days, considering the number of extremely talented people who find themselves "available" when they did not plan on it - like some of you reading this.
Taking on a contract of 3 or 6 months might not be what you WANT to do. Still, it will bring money in - and give you a sense of purpose. You also have the sense of being able to provide for you and possibly your family. Loads of people have been talking about their "extra time" since March. I'm not one of those folks. I was busy before COVID - and have been even more busy since mid-March.
There are some good and bad points to working by contract. There are also some things to remember as you look for the next opportunity. These can help you be successful and thrive while doing contract work - because it is DIFFERENT than when you are an employee.
These differences are not all one way. Some are good. Some are less-good. I'll look at some of these in the next installment.
At the Golden Perch
The next morning, Elanor told the others she intended to stay another night as she expected the conversation and explanations to go most of the day. Besides, the Golden Perch still had the best beer in all the Eastfarthing. All of them agreed to this excellent idea as it was clear they would talk through the day and well into the night about what they had learned and discovered.
They had a good solid breakfast with eggs and potatoes and rashers of bacon and fresh made brown bread slathered in butter. They washed everything down with large mugs of piping hot tea and felt like they were really home in the Shire.
Then other people began arriving. They sat down near the Travellers, but not too near. The innkeeper arranged a large board covered with paper and writing implements for Elanor and the Travellers to use. When the room was full and every seat taken, people still came in.
The Travellers all looked at each other, a little intimidated. There were more people gathered in this room to talk with them and hear their experiences than they had ever seen before. Amy and Bell looked at each other drinking another mug of tea. Esmerelda nodded and smiled and looked at Elanor and said “Is it time to start this? Do you want to go first or one of us?”
Elanor looked a little uncomfortable. “I’d better start. I think I know what I want to say. Can each of you be ready to jump in?”
Amy looked at her and laughed. “Of course we’ll jump in. Bell might trip and fall in, but we’ll jump in!” All four laughed. Amy never told jokes. This was unusual for her but set the tone for all of them.
Elanor stood and looked at the room full of people. She took another mouthful of tea and began speaking.
“You might remember a few months ago the four of us were looking for information and ideas around making and testing software. We’ve journeyed long and far and have some ideas now we think might help us. I think they might help us all.
“We started looking for this because we were frustrated. We tried to do things the way we were told to do them. We listened to the experts and the consultants who came in to show us and our managers what we were supposed to do to make good software and do good testing.
“We followed ‘the rules’ we were told to follow. There were still problems in production. Customers kept coming back reporting things not working right. When we went back to the experts to ask what we had done wrong, we were told we must have misunderstood something. Except we had the same understanding that the developers and designers did. Did all of us misunderstand the same things?
“We asked what we could do differently and we were told things like ‘work smarter, not harder’ which did not answer any of our questions or help with the problems we were finding. Our managers all said things like ‘There’s your answer! Work smarter!’
“Except none of them ever could say HOW to work smarter!”
Elanor was now warming up. Indeed. She had gotten “hot” as her father Sam would say. She began pacing, and walking around the room. She looked at each person in the room as she spoke and drew each into her story.
“The four of us do not work together. We don’t work for the same companies. We are friends whose parents were friends and we like each other and each other’s company. We began talking. Each of the companies we worked for, each of us got the same answers. All of us were having the same basic problems.
“Our management all said the same things, except they could not really help us. They could not offer suggestions or solutions. They all went back to the ‘experts’ they brought in to make things better.
“They were all different experts! They said different things and used different methodologies and approaches! They all said the others would not work!”
She paused and looked around the room. She realized she was shouting. Still, she had everyone’s rapt attention. Looks of recognition were spreading around the room. This sounded familiar to every person gathered there.”
“We began talking with others in software. Some of you here, were some of the folk we spoke with. Some said something like ‘Well, the experts told us we needed to try harder and make sure we did not misunderstand anything. They also said we must have misunderstood something because there were bugs in production.’”
She stopped as she saw nods around the room. Then she smiled. She knew she was on to something.
“We’re all Hobbits here. We like knowing what things are supposed to be and how everyone will act. We like things to be predictable and comfortable. We all like the idea of a party with friends and we all like the singing of the kettle on the hearth for tea. We like the idea of seed cakes at tea and a fresh loaf of bread with mountains of butter. We like things to be predictable and easy to understand.
“Except we could not understand why these things were happening. We could not understand why the ‘experts’ all had different methodologies to problems that looked much the same to each of us. We could not understand why the ‘experts’ all told us different things.”
She stopped again. She looked at her friends, then looked around the room. Elanor walked back to her chair and said “That is where we began. Things were not right, but we did not know what and we did not know why.”
With that, she sat down. The room was silent. Even the innkeeper and the wait-staff were silently waiting for what would happen next. As unusual as it seemed, this sounded to them like the beginning of a wonderful tale. To the other software folks in the room, this sounded very familiar.
Bell stood up. She smiled at Elanor and Esmerelda, then to her sister, Amy she said “I’ll try and not trip.” As they others laughed, Bell looked around the room.
“Elanor told you why we were looking for something different. We were looking for ideas we could use that would fix, or at least help, with problems all of us were having. So, I’ll tell you about the journey we took.
“We met in Bywater and talked a few times. We decided that since the problems seemed consistent all through the Shire, we’d look for other ideas. We went to Bree, first.”
At that, there was some murmuring. Hobbits visiting Bree was becoming more common, but nothing like what was done in the time of their grandparents and before.
She then told the story of visiting Bree and not finding any answers there. She told the story of the journey to Rivendell. At that, the Hobbits all seemed shocked. To go visit Elves seemed impossible for some in the room, and too much like an “adventure” for most. Hobbits still dislike the idea of an “adventure.”
She told them of meeting the Elves and Dwarves and Humans there, but did not speak of the Council with Elrond. She said they met Elrond, Galadriel and Gandalf. She spoke of meeting famous folk their fathers knew, Gimli, Legolas and Faramir.
Then she told a shortened version of the history Elrond gave at the Council and how the struggle against darkness and evil was not ended, even with the downfall of Sauron and Saruman.
“These are the things Elrond told us all. These are the things most of us were aware of, perhaps a little dimly, but these sounded familiar to us. We then spoke of what needed to be done.”
She sat down. There was silence in the room. Folk looked around, but no one really stirred. No feet shuffled. No one murmured. They waited.
Amy stood. “I’m not really used to speaking in front of groups. I don’t like it much even at work. My sister, Bell, told you of the journey we took. She told you who we met and of the history of how we arrived to this point. She did not tell all of the story. I can tell a little more.
“One evening when we were speaking with Gandalf, we learned something. First, we noticed Gandalf looked older. He had aged. This might not seem like much, but going back through all the stories of our parents, grandparents and great-grandparents, Gandalf was always there. He always looked much the same. Sometimes he’d appear more careworn than others, but he never really changed.
“That is not the case now. Gandalf has aged. He is getting older. We talked about that a little with him.
“He told us that when the One Ring, the Master Ring of Sauron was destroyed, the other Rings lost most of their power. Much of the strength of magic was diminished. Now, the Rings that remain, the three Elven Rings, are more limited and have less power than they ever did. The strength of the wizards is also dwindling.
“All the wizards are aging, not only Gandalf. The White Council has served its purpose. Radagast and most of the other wizards have headed to the West, to the undying lands where the Elves travel to. Indeed, Gandalf went there with Elrond once. They returned to help set the change in motion that we are here to talk about.
“Gandalf is now preparing to go West over the sea with the last of the wizards. I believe Elrond, Galadriel and all the rest of the famous Elves will travel with them this time and will not come back.
“Their time has finally come to an end. They saw us through the struggles of the Third Age of Middle Earth and set this Fourth Age on as good a path as they could. They travelled to help us with what we went to seek.
“They helped us by giving information we needed and confirming what rumor had already reported. Now they are leaving again. They will not return.”
She paused a moment and saw how every eye in the room was watching her. She looked at Elanor, who stood and began drawing on the paper behind her. One large circle in the center. Then off to one side, nine interlocked circles. Above the large circle, she drew three interlocked circles. Then she drew seven more circles, also interlocked.
Amy went on. “By now you have all heard the rhyme about the Rings, yes?
Three Rings for the Elven Kings under the sky,
Seven for the Dwarf-Lords in their halls of stone,
Nine for Mortal Men, doomed to die,
One ring for the Dark Lord on his dark throne,
In the Land of Mordor, where the Shadows lie.
One Ring to rule the all, One Ring to find them,
One Ring to bring them all and in the darkness bind them,
In the Land of Mordor, where the Shadows lie.*
There are two things important about that. The first, is the One Ring had dominion over all the others. When that was destroyed, everything made, built or controlled by the others began their decay and decline. The Nazgul, the Ringwraiths who once were Human Men-kings and lords, were alive only through the power of the One. When that was destroyed, their Rings died and them with them. The Dwarven Rings were already destroyed or held by Sauron. Those were also destroyed then. The Elven Rings remain, but with only a shadow of their powers.
“The elven Rings were not made by Sauron or ever touched by him. With his destruction, they also began to decline. But the strength in them was preserved somewhat by the powers of the Elven smiths who made them. We might call them “magic” except they would not describe it so.
“There is another thing which is important. Vitally important to those of us who make or test software.”
Amy looked at Elanor, smiled and sat down.
Elanor pointed at what she had drawn. In a clear, ringing voice, she said “These are all the ‘Rings of Power’ which were ever made. These are what we would call ‘Magic Rings.’ There are no other true, real, Rings of Power. None.
“Those who claim to be the sole, final authority on software and testing, are not. They are either deceived into believing themselves, or they are themselves deceivers.
“There are NO TESTING RINGS. There is no magical power that grants all knowledge. There is no source that gives all knowledge of all possibilities. There is no source that tells us everything there is to know about software and testing it.
“Not even experience combined with study and scholarship can give any person such knowledge and ultimate mastery. Those who tell you there is? Or they know this is always true and that is not? Those who claim that authority? They are nothing more than Saruman was at the end! They talk smooth as silk and sweet as honey and draw you in by fair words until you are trapped.
“There is no person who knows what is right and perfect for all teams, projects and organizations! There are none who have that power. Those who claim to know what is best are trying to sell you something. That is why no two of them agree!”
Elanor was nearly glowing red. She looked around the room full of shocked and amazed Hobbits. She looked at her companions, all of whom were smiling at her and nodding. Then she sat down.
At that, every person in the room began speaking at once. In the pandemonium of the moment there was shouting and gesturing and much waving.
Esmerelda stood and walked to the center of the room. She was tall for a Hobbit. She looked around the room slowly. Silence seemed to radiate from her and all the voices dropped away.
She spoke quietly, forcing all to listen. “All of you recognize the truth in these words. All of you recognize a few simple facts. The ‘experts’ keep coming back and charging your companies more and more for ‘training’ in the ‘correct way’ to do things. And still, nothing really changes. The ‘experts’ tell us to use their terms because the others are confusing and misleading. No two sets of ‘experts’ agree with what terms are not confusing.
“The next question is, what can we do about it? I think it is simple. If all that has been said makes sense and rings of truth to your ears, then believe it. We don’t need to change all of our terms to suit some outsider’s definition of what words mean.
“If your company has a set of terms which everyone understands and agrees on, fine! Use them! If the practices which are being mandated work and no significant problems are found in production and customers do not complain, then GOOD!
“If the practices being mandated result in problems being found and customers complaining, how long will you wait before saying “This doesn’t work!”
“The EXPERTS don’t have the rings to give them authority. There aren’t any. If they have one, they made it themselves - and their practices are as flawed as their ring-making! Turn them out! Send them packing as Saruman and his ruffians were sent packing!
“We’re Hobbits! We don’t like change! We like being forced to do things that don’t help others even more! SO CHANGE!
“Our fathers returned from their journey with Frodo Baggins and turned out the ruffians then. We can do the same now! As before, we have been so comfortable, so not willing to change because it might upset things that we have failed to see that things are being upset a little at a time all around us.
“And because we don’t like upsetting things, we have not said anything for far too long!”
Now her voice rang out. The face of everyone who heard her shone with a light they had not experienced and could not explain.
“I say ENOUGH! We are simple folk but not stupid! We know what works and does not work! We don’t need people to profit from our struggles and problems by illusions and falsehoods. ENOUGH!”
Someone in the back of the room shouted “YES! ENOUGH! You’re right!” They began cheering. Cheering wildly. The other three Travellers stood and joined her in the middle of the room. Then everyone was standing and cheering.
Esmerelda stood on a chair and held up her hands. The cheering and yelling died down. She said “I am Esmerelda Took, the daughter of Peregrin Took. These are Amy and Bell Brandybuck, daughters of Meriadoc Brandybuck. This is Elanor Gamgee. She is the daughter of Samwise Gamgee, companion to Frodo Baggins. She is also our leader and the one who inspires us to be better.”
The cheering and applause was thunderous, which is something for Hobbits who normally are quite restrained.
Elanor stood on a chair and held up her hands. When they were quiet, she spoke.
“All of you know the problems found. All of you can study techniques in testing and test design. We can help you with what we have learned. Our lessons might not help you in every instance. But they can help you think about things and learn from them. They can help you learn from each other. They can help all of us be better at what we do.”
With that, she got down from the chair she stood on. The people gathered all talked excitedly about the chance to learn things they could apply as needed, not as they were forced to do. They were excited to find solutions that fit their problems, not ones that solved someone’s problems 20 years ago.
They knew they could be free to find their own path forward.
Raise the Shire! Now! Wake all our People!
Shire-folk have been comfortable so long they don’t know what to do.
They just want a match, though, and they’ll go up in fire.**
* JRR Tolkien, The Fellowship of the Ring, ©JRR Tolkien, 1954, renewed 1982, Houghton Mifflin Harcourt Publishing, Boston, 2014, p. 49
** JRR Tolkien, The Return of the King, ©JRR Tolkien, 1954, renewed 1982, Houghton Mifflin Harcourt Publishing, Boston, 2014, p 983