At Bree

This is the fourth part of the story which began here. The second is here.
The third is here. This saga continues below.

All that is said among us is that far away,
over many hills and rivers, live the halfling folk
that dwell in holes and sand-dune...*

Four brave testers, related to the Tooks and Brandybucks, looked around them and began thinking about how things were. They began thinking about how things might be. They began thinking about how things could be better.

These testers looked around and wondered what they might do. They kept seeing problems come up even when they followed the rules. They worked hard to make sure the rules were strictly followed and there were still problems.

They asked for help and were told they must not have been doing something “right.” They showed what they had done to plan for testing. They showed how they had done the testing. They showed the bugs they found in testing. And they showed what bugs were found in production. They asked what they should have done to know something like those bugs might happen.

Answers were not helpful. “Work smarter.” The testers drinking their beer at The Green Dragon, in Bywater (nice place if you ever go there) talked quietly amongst themselves. They compared results with each other. They compared the responses they received.

Then they very quietly began talking about other things. They began wondering why it was that the “experts” were not able to give them guidance or even suggestions on how to do things better. They wondered why, no matter how hard they tried, they still had problems.

Then they began wondering.

They wondered if other people had similar experiences. They began quietly asking others if they ran into things as they had. They wondered if they had gotten any better help in how they should work from the experts.

They got answers along the lines of “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.

But we don’t know how we could have misunderstood anything because we always asked the developers to make sure we understood the same things.”

So the testers decided they needed other sources of information. Other ideas they could try to make their testing better.

The four of them decided to head to Bree. 

None of them had been there before, but they heard there might be other testers who could help them. They might encounter people with different ideas and different experiences. They might find the solution to the problems they had. 

They might figure out why the testing rules they were supposed to follow did not eliminate the bugs found in production.

After some adventures, they indeed met people with different views.

“Testers out of the Shire! Strange.This hasn’t happened in a long time!” 

Still, it was good for them to get out. What they found was that many people found testers to be imaginative. They met testers from Bree and other wanderers. There were people who sat quietly and listened to the conversation. They did not join in the stories. They did not sing along with any songs. They simply observed. And watched.

Some of the Bree testers warned them that doing things “against the rules” wasn’t natural. Bad things would come of it. They were cautioned about taking up outlandish ideas. They were warned against taking up with strangers and wanderers who did not seem to follow any rules but their own.

What they found was that many were so comfortable, so convinced of the “rightness” of what they were told, even when they thought something was amiss, any fault lay with themselves.

To the four travelers, these seemed predictable yet sad. They knew something was not right and were determined to seek out what it was, or at the least, a better way. 

They continued from Bree, looking for signs and portents and reading and talking with people. They talked with wandering Elves and Bombadill (Iarwainn Ben-adar, Orald.) They knew things were wrong. They knew things needed setting right.

They knew they needed something. 

* JRR Tolkien, The Two Towers, ©JRR Tolkien, 1954, renewed 1982, Houghton Mifflin Harcourt Publishing, Boston, 2014, p 544. 

The Story continues here.

Virtual Pipe Band Rehearsal Tips

At Home Band Rehearsal Tips

Part of the fun of playing in a pipe band is getting together with bandmates at rehearsal, work hard, come out sounding better at the end than when you went in, and having a bevvy and a laugh after. The challenge comes when the band hall is closed or unavailable thanks to storms, snowfall or highly infectious pandemics.

Here's a few ideas to keep your playing sharp and keep everything in shape so you can hit the ground running the next time you can physically get together.

Tip 1 - Remember, you Practice at home and Rehearse with the Band.

The PM/Lead Tip may chose to work on music and break things down while sitting around a table with chanters and pads. Unless you were handed the music THAT DAY, a diligent musician will have worked on in and come in prepared to play it with the group. Practice at home. Get it as close to "street legal" as you can on your own. Then bring it in for a reality check. 

Tip 2 - Getting Street Legal.

Most people practice and thing "OK, that wasn't too bad" or "hmm, that could be better." What is hard is concentrating on what you are doing, and listening for HOW you are doing it. I know from my own experience that I like to delude myself in this way. How do I fix it?  Same way I suggest to everyone now (and not just when "isolated" or "quarantined".) Record yourself playing. Play it back and listen. Listen critically. Listen for mistakes, listen for ornaments with "cheating" parts in them - like not getting "quite all the little" notes in, or choked moves. Listen for rolls not quite being carried through to the end. Listen for the little wavers in tempo. Listen for the BIG wavers in tempo. Do it again until you can't hear it yourself.

Tip 3 - Getting more street legal.

Now for the harder part. Get a metronome going. Set it a couple beats per minute SLOWER than the PM says he wants the tunes played. For example, if something is to be played at 76 beats per minute (bpm) in competition or performance, set the metronome to 74 bpm. Play it at that speed and record it. It will likely feel unnaturally slow. Listen to the result. How are the ornaments? Relaxed? Clean? Consistent? Or are they still kind of choppy? Is one "fine" and the next a trainwreck? Repeat this process until every ornament, every move, every embellishment is consistent and identical to every other embellishment of that type. Then, set the metronome to the "performance speed" and play the tunes through again. While recording. Play it back and listen critically AGAIN. Are the ornaments still good? or are the fuzzy and icky? Slow it down and play the tune until you have no choice but to play it right. Then speed it up again and listen again. (piping/drumming version of 'shampoo, rinse, repeat.)

Tip 4 - Reality check.

When you have the tunes at the correct tempo, and you cannot hear any more problems or mistakes, make one more recording and send it to the PM or Lead Tip. Ask THEM to listen to it. Ask THEM to critique it.

Tip 5 - For PM/DS.

Make recordings at performance speed, with a metronome in the background, getting played the way YOU want the music played. (Better make sure your stuff is spot in as well!) Then send it/share it with your respective corps, and the band as a whole! That way, the individual drummers can play along with the PM's recording and hear how their playing fits with the pipes. Individual pipers can play along with the DS and hear how their playing fits with the drums. 

Finally.

This won't replace in person rehearsal completely. However, it WILL help your playing overall, so when you get together in person, for real, you can work together more easily.

Just one more thing.

You can do this any time. You don't need to wait for a blizzard or a massive pandemic to practice this way. You can do this all during the off-season and be even more awesome come performance/competition season.

The Uruk-Hai

This is the third in a series of posts.The first is here. The subsequent one is here.
This saga continues below.

 

Halflings! But they are only a little people
in old songs and children’s tales out of the North.* 

Working in isolation of others was considered wrong in prior ages. Then
it became normal. Each person had a specific role to play. Each person
had a specific function to fill. Project work lined up for Business Analysts,
Designers, Developers, Testers and everyone else. The Project Manager
kept things moving. The Project Manager kept people on time and on
task.

Of course, it was not quite stated that way. 

There was talk about “industry standards” and “best practices.” There
was talk about how the goal was to deliver value. There was talk
delivery and “stretch goals.” There was talk about how the “stage
gates” would ensure everyone was in agreement, and how thrash
would be reduced if not prevented.

Making a change to anything became huge after there was a “sign-off”
at the “stage gate” for that area. “Why wasn’t this found before? How
come no one raised this issue?”

To drive efficiency the thinking process of people who found solutions
to needs by software was replaced by templates and tools and “linear
process models.” The people doing the work became less important than
the process.

To emphasize this point, people doing specific tasks were given special
rewards. They are needed to make things happen. Differences in pay 
rates were introduced. People not in those roles were told their role, in 
relationship to the more special people.

Training programs in companies, then colleges, universities and even 
trade schools emphasized “write code” over everything else. There was
little attention paid to other aspects for some of these.

Ideas around “why” were replaced by technical “how.” Exposure to logic 
and systems thinking were reduced to elements of a survey course, 
instead of being courses themselves. Testing was mentioned less and 
less. In the end, a basic mention of “unit” testing might occur. 
Depending on the school or training facility.

The results were predictable.

Developers became “ninjas” and “rockstars.” Everyone else served 
them. People not willing to work in those circumstances and conditions 
drifted away to other fields.

Other people became comfortable with this way of working. They 
were paid reasonably well and as long as they did not rock the boat 
too much, there were no real problems.

Until something did not work or something went wrong.

Then all the attention landed on the people doing testing. They must 

not be testing “right.” Because, if they were, there would not be any 
problems and the code would be bug-free. And problems in “production”
would never occur.

The fault must lie in how the testers were testing. Because the 
developers were ninjas and rockstars.

The idea of “designing” tests was considered ludicrous. There was no 
real “design” needed to write test scenarios. After all, the requirements 
were very clear. There was no way the testers could have misunderstood.

There is no way the testers could have interpreted the requirements 
differently than the developers did. And if they did, it is because they
are not ninja rockstars!

So a pack of Orcs are turned loose on the testers. 
“Where there’s a whip, there’s a will!”**

Testers are driven with whips and threats and clubs to do exactly what 
they are intended to do and not contradict the developers because the 
developers are ninja rockstars and the testers are not. And so, after 
berating the testers, the Orcs force the testers to apologize and make 
all their tests pass, because everything is as the developers meant it 
to be.

Until the people who asked for the software, the users and customers, 
try using it.

Then the testers are berated for “not thinking outside the box.” 
Because if they had, they could have reasoned with the developers 
and explained, politely and with soft, understated voices (so as to not 
offend the developers) why they thought something “might be wrong”
with the solution designed by the developers.

So, forced to drink the foul drink of Orcs and blamed for things being 
wrong, even when they tried to warn people that things looked wrong, 
the testers settled into a simple, plain existence. They simply said 
they’d “do better” on the next project.

And they documented how their test scripts lined up with the 
requirements and the design and how they could make everything line 
up perfectly. As long as people did not mind that things were not really 
right. But because they did precisely what they were told to do, they 
hardly got yelled at at all.

So, they grumbled a bit and got used to it. They went to the Green 
Dragon in Bywater and drank their beer and ale.


*JRR Tolkien, The Two Towers, ©JRR Tolkien, 1954, renewed 1982, Houghton Mifflin Harcourt Publishing, Boston, 2014, p 424. 
**JRR Tolkien, The Return of the King, ©JRR Tolkien, 1954, renewed 1982, Houghton Mifflin Harcourt Publishing, Boston, 2014, p 910. 

The story continues here.

On Business Continuity

This is aimed at Managers, Directors, VPs, and C* suite people. The thoughts are drawn from my experience in well over 20 years in software as a maker, improver and thinker.

Quite a few years ago, I was tasked with reviewing and testing the Disaster Recovery and Business Continuity plans for the company I worked for. I skimmed the existing documentation and asked what level of "disaster" would be the worst we could plan for.

For example, a fire in the main office where the mainframe and all the primary servers were located? Floods in the distribution centers (DCs) preventing operation? Catastrophic loss of power to the DCs that might prevent the facilities from operating? Sure, there are backup generators - how long can they operate with the fuel on-hand? Under what circumstances do they not work?

The response was something like, "No, Pete. Only worry about the computer systems. We need to make sure that we can continue to operate business as usual." My response was something like, "Those will likely be the least of the issues. Your people will matter far more than your computer systems."

I remember the contingency planning at that company for "problems" with Y2K. Loads of meetings and loads of work done and piles of software changes and tests and massive overtime for years in advance. We were reasonably certain that everything we could make ready was ready. We spent massive effort in 1999 testing everything we could test.

One meeting, someone who must have read something on the internet, (where everything must be true, right?) asked "What happens if the power grid goes down? How do we keep our facilities safe? What are your plans for keeping looters from ransacking our inventory?"

We blinked. Silence in the room. A colleague, manager of one area who was also an officer in the Army Reserve, quietly said, "In that situation, we'll need body armor, M-16s, .45 cal side arms and a thousand rounds of ammunition for every person scheduled to work on site."

This was met by horrified looks. He then said, very calmly and sounding more officer-like than I had heard him speak before, "And none of us will be here. We'll head for home to take care of our families. That is far more important than 'guarding' warehouses full of stuff."

My Point

No matter how much calm you want to project, no matter how much your people want to appear calm, Western society is facing something it hasn't seen in years - 100 of them to be precise. Rapidly spreading, undetectable (until symptomatic) illness that has a growing global death toll (last I report I read yesterday was a fatality rate of ~200 deaths a day in Italy) has got some folks spooked.

The idea of "quarantine" and "self-isolation" hearkens back to public pools and community areas being shut-down because of Polio outbreaks. The idea that people can be contagious without knowing it - without "feeling sick" - is part of what makes this different than the more recent flu outbreaks often referenced by pundits.

Schools shut down for 3 weeks, as they are where I live, and canceled sporting and other events might appear to be an overreaction. The point is to stop something potentially bad from becoming horrific.

People are going to be nervous and on-edge. Allow for that and acknowledge that. Let them be like my former colleague who intended to take care of his family above all else.

Give them the space to be human above being a "resource."

Recognize that "business as usual" is likely not going to be what it was last month or last year.

Working from home is a start. People will still be distracted. Small children will likely not understand why they are not in daycare, and are home with everyone when it is not a holiday. Older ones will have their own questions. They may not have an area set up to work conveniently out of their house. Not everyone has that empty, unused room or corner of a room that can be turned into an "office" only for work.

Let people discover their new equilibrium. Let them regain their balance. Then help them however they need it.

And ask them what help they need.

The Shadow of the Past

One morning long ago in the world,
when there was less noise and more green…*

There was a time when Developers were Programmers. Or maybe Programmer-analysts.

People talked with customers and business users about their needs for software or changes to that software. People talked about requirements and design. They talked about file systems and how information should be stored, referenced and accessed. They looked at other forms of file systems and found solutions to data problems. People looked at databases and designed changes to them.

People wrote code and developed software. They talked with each other. They talked with loads of people who might have ideas. They helped other people with their software problems, just as they received help with their problems. They talked with the customers and business users while working on the code, talking about what pieces did what things. They showed them what screens and reports looked like and had demos the customers could talk through and give feedback on.

They sat down together and figured things out without regard to title or position to make the best software they could make, to fill the needs of customers and business users. They worked to deliver functionality as quickly as they could - sometimes one piece at a time.

People tested software. They found unexpected behavior. They asked questions. They looked at the answers and compared the answers to what the design and requirements described. If they still could not find a complete answer, they went back and asked the customers or business users.

These were all the same people.

To be successful, teams and individuals needed to support each other. Of course, not everyone was equally skilled in all areas. Everyone had skills that complemented everyone else on the team. Everyone could help others be better at the tasks at hand.

People NEEDED to help each other. Everyone learned and grew.

This was long before “Agile” or “lightweight development methodologies” which Agile grew out of. 

This was before the push to commoditize and monetize software development. 

This is when I started working in software. My memory stretches across several ages of software.

I remember well the banners and slogans that came after these eldar days. I remember how they proclaimed things would be better. I remember how they said software would be made faster and be more predictable. I remember when the company where I worked reorganized everyone into different roles.

Before, their “reorganizations” had involved people reporting to different managers or being given systems they would be responsible for.

This was different.

A Dark Shadow fell over Greenwood. People began calling it Mirkwood. “Modern Scientific Management Theory” began getting applied to making software. No longer was it “research and development. It was not considered “Manufacturing.”

Programmers would program. Sometimes they would do “analysis” work. Sometimes they would be given a set of requirements and told to make that software. Except, things were different now. 

Programmers would not “gather requirements.” That was for a new class of worker, “Business Analysts.” Programmers would unit test their code, but other people would test it “fully.” 

In time, “Designers” would do “design” work. And “Architects” would “architect systems.” and DBAs would handle anything to do with database structure. Programmers could still write code to access it, but needed to make sure any code they wrote which might “update” the database was “of sufficient quality” to not cause problems for the database.

In time, Programmers became “Developers.” They did more than simply program. They developed “solutions.” 

People were expected to focus on their immediate tasks. “Working together” was to be avoided unless there were significant problems. Everything was to be clearly documented. 

Developers "developed." Designers "designed." Testers "tested." Project managers supervised everyone's work and made sure they stayed on task and on time.

If someone didn't, the Project Manager made sure "the Boss" or "the Great Eye" knew about it. There would be "repercussions." 

The story continues here.

*JRR Tolkien, The Hobbit, ©1937 JRR Tolkien, renewed 1982, Houghton Mifflin Harcourt Publishing, Boston, 2014, p 5.