Arduino and the MedeaWiz Sprite

I often get asked to help out with odd projects. I’ve done electronics for several displays at the St. George Children’s Museum, as well as having consulted on several themed environments (Jungle Land at Mersal Village in Jeddah, Saudi Arabia, the now defunct Pirate Island Pizza, and Tuacahn Amphitheater, to name a few).

During the Corona pandemic, the St. George Children’s Museum has been hard at work building some new environments, and fixing up older displays. One display they had me work on was in the Transportation Exhibit (sponsored by SkyWest Airlines). In it, the have a “luggage scanner”, which has a a display showing a looping video about SkyWest. When luggage is passed through the “scanner”, a break beam is triggered, which is supposed to show one of four possible luggage “scans”. Thing is, it never worked quite right.

I had given the onsite tech some diagrams for how to wire up some relays. The idea is that the break beam sensor would trigger a relay hooked up to an Arduino. The Arduino would then randomly trigger one of four relays connected to the MedeaWiz Sprite, which would play on of the four possible scan videos.

One issue I discovered was that the relay accepting the break beam sensor was a solid state relay. Now, if you’ve ever used relays, a mechanical relay doesn’t care if you’re triggering AC or DC. But on a solid state relay, it matters. If you use an AC Solid State Relay, once the relay is triggered, it will always pass DC current. We’ve been moving all relays in use at the museum to sold state relay, so you don’t get the mechanical “chunk” sound as the relay turns on and off. For some reason, during Corona, I couldn’t find DC to DC Solid State Relays anywhere in the US, only out of China, which was further delayed due to the pandemic. So, I’ve had to use mechanical relays (until my Solid State Relays show up).

One thing they did do was to use a Sprite Video Player Input Adapter. This adapter will take up to 8 contact relays, and send information into the Sprite Player as Serial commands, since natively, the player will only accept one contact play command. This never worked correctly for them (I get the feeling the chips on the device got fried during experimentation).

My idea was to use the Arduino to communicate directly to the Sprite using Serial. The first issue was I had to order in a TRRS to wire terminal adapter, so I had a point to wire in on (and I couldn’t use the Sprite Video Player Input Adapter, since it has translation chips embedded on it).

As I went through the device manual, the manual recomended passing all Serial commands from a PLC through a MAX3232 chip, to ensure RS232 commands were read as TTL. Well, I tried this. I knew I was close to getting this working, because when I would send a serial command, the base looping video would reset. I tried several permutations of wiring configurations, as well as Serial command structures (“Send one byte, Decimal 1 (Binary 0000 0001, Hex 01) to play file 001.xx”, etc). No luck.

As I read more on the MAX3232 chip, and is use on Arduino’s, I realized the Arduino is sending and receiving as TTL, and many makers use MAX3232 to translate into and out of RS232. So, I experimented wiring directly to the Sprite from the Arduino. After going through the command permutations, I finally was able to get everything working.

So, here’s how to wire it up. As you’ll see later in the code, I’m using Digital Pin 10 as Rx, and Digital Pin 11 as Tx on the Arduino.

Arduino Sprite Wiring
How to wire an Arduino to send serial to a MedeaWiz Sprite

When communicating over Serial, Rx is sending to Tx, and Tx to Rx. On the Sprite, you can have a looping video, with the name of 000.xxx (there are a large number of video file formats supported. We used mp4, so our file is 000.mp4). Triggered files would then be 001.xxx, 002.xxx, etc, up to 200.xxx.

Below is the code I’m using. Once I got it figured out, coding it was pretty strait forward.

#include <SoftwareSerial.h>

#define DELAY 23000 // 23 second delay while the video plays.
                    // Video is actually 18 seconds, but this gives it some leader time
#define rxPin 10
#define txPin 11

#define Sensor 4 // relay from break beam sensor

int sensorState = 0;
int lastSTate = 0;
int randomNumber = 0;
int prevRand = 0;

char one; // video one
char two; // video two
char three; // video three
char four; // video four

SoftwareSerial mySerial(rxPin, txPin);

void setup() {
  one = 1;
  two = 2;
  three = 3;
  four = 4;

  pinMode(Sensor, INPUT);
  digitalWrite(Sensor, HIGH);

  pinMode(rxPin, INPUT);
  pinMode(txPin, OUTPUT);

  Serial.begin(9600);
  while (!Serial);
  mySerial.begin(9600);
  randomSeed(analogRead(0));
}

void loop() {
  // Read the sensor state
  sensorSTate = digitalRead(Sensor);

  // check if the sensor beam is broken
  // if it is, the sensorState is LOW
  if (sensorState == LOW) {
    // Randomly choose a relay to fire
    randomNumber = random(1, 4);
    if (randomNumber == prevRand) {
      randomNumber = random(1, 4);
    }
    showVideo(randomNumber);
    delay(DELAY);
  } else {
    delay(500); // If beam isn't broken, recheck in 1/2 a second
}

void showVideo(int id) {
  if (id == 1) {
    mySerial.print(one);
  } else if (id == 2) {
    mySerial.print(two);
  } else if (id == 3) {
    mySerial.print(three);
  } else {
    mySerial.print(four);
  }
  prevRand = id;
  Serial.println(id);
  Serial.println("");
}

It is possible to use the base Serial, and ports 0 and 1 for the Rx/Tx. By using the SoftwareSerail package, and another set of ports, you can use the Serial Monitor and println statements to monitor the application (old school debugging techniques).

The last change I may make is using a relay to fire when the beam is broken. I’ve used small break beam sensors directly into the Arduino in the past just fine. The break beam they used is a commercial unit, powered externally (which is why they chose to use the relay, for circuit protection). Since this has been in place for a while (just playing the base looping video), I haven’t been able to get the specs on the sensor (which is why I’m leaning towards using the relay). I’m installing later today, so I may give an update.

UPDATE – The break beam sensor they are using is a 12v dc unit. The relays they have on hand are 5v dc relays. They’ve played around with step down transformers, to transform the 12v dc to 5v dc. They can get the relay powered up, but not trigger correctly. Rather than mess with all that, I found a DC-DC relay circuit that can be powered from 3 – 32 v dc (and can trigger 3 -60 v dc at up to 2 amps). I’ll be putting that inline when is shows up (soldered to a breadboard with terminal block headers to make it easier to deal with).

Internal Conflict

After a discussion a few weeks ago with a colleague about cars, I’ve found myself having an internal argument and conflict over his deep love, Tesla. You see, I’ve become a bit of a petrol head. I’ve always had inclinations that way when, in the late 80’s, my father purchased an old 1966 Ford F100 from a neighbor, to help give the neighbor some extra cash to help them moving.

The truck had a wood rack in the back, and the entire vehicle was a rusting white. My data beefed up the suspension on the back end, so he could haul a large amount of weight when hauling equipment.

Our neighbor was a bit of a weekend warrior. The truck was built for racing, and was WAY overpowered. When my older brother got his drivers license, he ended up getting that truck to drive (since it was an extra vehicle). The truck was eventually handed down to me when I got my license.

The vehicle was a complete gas guzzler, and a whole lot of fun. This big, heavy, loud old truck could beat most cars at a green light (I’ve dusted many Corvette’s and Camero’s in this truck).

I also gained a basic knowledge of auto repair, since it would break quite regularly (for the uninitiated, older vehicles tend to break more, and overpowered vehicles tend to break more, due the stress they put on the rest of the vehicle).

Eventually, the end of my Junior year of high school, we had to put the old girl down. Two weeks before the end of the year, between my brother and I, we had stripped to transmission forks smooth (you would put the truck in gear, but the gears no longer had the ability to engage, so you didn’t go anywhere). We ended up selling the truck to a scrapper for $30 (the only one who wouldn’t charge us a towing fee). Oddly enough, the scrapper put another transmission in the truck, and drove it around town. Our family had moved out of state, and a lot of my friends didn’t realize we had left already, due to that truck standing out like a sore thumb in that town.

For most of the years since, I’ve driven vehicles that got me from point A to point B, but rarely anything that excited me. Until last year. I ended up buying a 1997 BMW 328i convertible from my friends daughter. Given it’s age, I realized I would be doing quite a few repairs on it. But, the price was right (especially for just under 100,00 miles), and when things are working, it’s a blast to drive. Even better on a warm evening with the top down (convertible therapy). It’s a car that I get excited to drive (admittedly, it’s a bit of a mid-life crisis toy).

While I’m not a mechanic by any stretch of the imagination, I have come to enjoy tinkering on my cars, not just the BMW. I’ve come to appreciate the ability to do repairs, and keep my cars going far longer than most of my contemporaries (all while forgoing a car payment).

Now, when I was having the conversation with my colleague, he’s a Tesla devotee. Where we live is a semi-rural area, with an abundance of retirees. We’re 2 hours from the next big city (Las Vegas, over the state line), and 4 hours from the state capitol. We disagreed that Tesla’s were made a lot of sense for most of the populace here. While I agree they make a lot of sense for urban centers, out here not so much. Of course, that also comes from my viewpoint, where I never know when I’m going to jump in a car and drive 2 hours to Las Vegas, or more commonly, 6 hours back to California. And I rarely have the time to sit for 45 minutes along the way, or at the end to wait for my vehicle to recharge.

He did agree that he would never want to take his Tesla to our State Capitol (due to lack of charging stations), but has no inclination of what I see as wasted time. Don’t get me wrong. I do find the technology very interesting, and a step in the right direction for urban blight. I also don’t buy in to the fact that these vehicles are zero emission. Yes, there is no emissions coming out of the vehicles, but the energy is generated someplace, so it’s displaced emissions. While there are several nuclear power stations in the United States, and a handful of solar and wind stations, the bulk of our power is still generated by coal, which does create emissions. It does calculate better than a vehicle due to scale, but emissions are created.

What also is rarely talked about it the toxic wastelands that are being created in places like South Africa, in extracting the rare earth minerals required to create the batteries. No seems to like to talk about this. Technology always has a double edged sword.

This isn’t wasn’t what created my internal conflict. What has been causing my conflict is what’s coming next: Transportation As A Service. This is the next logical step for urban congestion. Even the administration of my smaller city is touting the future of driver less buses. On the one hand, I completely recognize is large populations the pure efficiency of an automated mass transportation system. Aside from the displaced emissions, and the congestion removed from the roads, the lack of accidents will make huge difference to our lives.

The payoff though, is the loss of freedom, to go where I want and when I want. Also, is the loss of the pure thrill of dropping a gear in beefy vehicle, to raise the revolutions of motor, and release the new bounded torque, to feel the explosive velocity, and rocket around the idiot in front of you going 5 miles under the speed limit for no apparent reason.

I hope that when Transportation as a Service becomes reality, those of us who love vehicles will still have the ability to enjoy that technology.

Didn’t Your Mother Tell You Not To Play With Your Food?

Kind of an odd title. I thought it was more interesting than, “Playing with PI”. Raspberry PI, that is.

For the uninitiated, the Raspberry PI was designed to be a low cost way for students to learn about programming, at a very low cost. What has come out of this ideal is an amazing powerful piece of technology, with amazing possibilities.

The average PI board costs around $35. A full kit that comes with the board, power supply, case, SD card (the hard drive for the device), heat sinks for the processor and GPU and cables runs between $75 and $120, depending on variations in the kit, and the version of PI used. The boards have an HDMI adapter (to make it easily usable on about any modern monitor), a headphone 1/8″ trs jack (which works well with external speakers), an Ethernet adapter, and four USB jacks. Most also have on-board jacks for connecting small LCD screens.

There are also a set of GPIO pins, allowing custom peripherals to be easily added. These can be used for input and output. They can be used for inputs as simple as buttons or proximity sensors, or outputs to relays or LED’s.

Most users use Raspbian as the Operating System on Raspberry PI’s. Raspbian is a stripped down version of Debian, with a modified Kernel to run efficiently on the small platform.

Other Operating System options include Ubuntu MATE, Ubuntu Core, Ubuntu Server, Windows 10 IoT Core, OSMC, LibreElec, Mozilla WebThings, PiNet, RISC OS, Weather Station and IchigoJam. As this exists in the Open Source world, new options pop up all the time.

There is much more software available for the Raspbian distribution, though if you’re familiar with Linux, most of the software can be adjusted to these other Operating Systems.

When I started working with Raspberry Pi, the current model was the Pi 2 Model B. The downside to this device was the lack of on-board WiFi. Adding WiFi turned out to be more of a headache than I had hoped for, due to cheap Chinese USB/WiFi dongles, with bad drivers.

With the introduction of the Pi 3 Model B+, WiFi comes built in, and works beautifully. This is currently my favorite board to work with. Earlier this year, the Pi 4 Model B came out, in 3 flavours, dependent on memory size (1 GB, 2 GB and 4 GB). It offers a much beefier GPU, that can handle 4K delivery.

For most of my projects, the PI 3 Model B+ hits all the specs I need. It’s the same price as the Pi 4 1GB, but there are some support issues with certain libraries and the Pi 4 (which you should see resolved over time.

Another device I’ve been playing around with is the Pi Zero and Pi Zero W. The Pi Zero is a smaller format (and less powerful) version of the Pi. It’s also even cheaper. The Pi Zero W includes WiFi on-board. The GPIO pins can be soldered in, if you need them. There is also a Pi Zero WH that has them pre-soldered.

The Pi Zero may be less powerful, but it’ll still play video (4K is not an option).

Here’s a list (with links) of the models I like to play with:

Passions And Alignment

It’s funny how life works. The highs and lows, ebb and flows are what makes life interesting.

My first career was in live production. Lighting, Sound, Rigging. Doing concerts, theater and conventions. I honestly very much loved that career. I spent the last five years of that career as the Technical Director for a fairly large theater, with a mid-sized events arena, located in a smaller market.

The problem was, being in a smaller market, there was a fairly low cap to my income potential. Eventually, my wife and I realized that in order to make the income I had projected for myself required a change, either moving to a larger market, or changing careers. The biggest downside to moving to a larger market was I would inevitably end up working on the road, which isn’t a great environment for a family, plus my wife prefers the size of community we live in.

Since I had been involved with programming since the third grade, furthering my education in this area was a natural fit. The college I ended up attending required at the time a minor for all students going after a Bachelors degree. While many of my Computer Science compatriots chose a Math minor (which only required a handful of extra classes), I viewed my degree from an investment standpoint. I figured if I was having an issue getting a job as a Software Engineer, there was very little chance of getting a job as a Mathematician, especially with a Math minor. So, I did a minor in Network Administration, figuring there would always be someone needing a computer fixed.

This choice ended up being a wise one. I finished my degree two months after the dot com bubble burst, pretty much killing the software industry in the Unites States. Between 2002 and 2009, I worked as a Software Engineer for about two and a half years. The rest of the time was as a Network Administrator (a few times working as a Software Engineer who also did Network Administration for the companies I worked for).

In 2009, I was asked to help build a pirate themed restaurant. At the end of my live entertainment career, I was able to help build a theme park that was installed in Jeddah, Saudi Arabia. I worked on two contracts for that park. The first was doing lighting, audio, video integration and show control for a “haunted mine ride”. I received a second contract doing lighting, audio and show control throughout all the walkways of the park, and a few specific themed areas.

With that experience, I was able to design the show segments, lighting, audio, special effects and show control for the restaurant. Several of the special effects I build were using small, discrete controllers, based off of the Basic Stamp processor. I had never done this before, and was an enjoyable learning experience.

After a few years working with the themed restaurant, thing started to slow down, and I needed to find other work. I did some contract mobile programming in the interim, but finally went after a full time development job. I ended up getting hired by an airline as a C# developer.

After working here a few years, I ended up transitioning to another company as a PHP Software Engineer. Through some individuals I had worked with previously, I ended up, on the side, starting to build displays for a local Children’s Museum. The museum has a great staff that builds and conceived most of the displays. They use me to add electronics, or build really odd projects. As part of this, I learned how to build interactivity with devices like Arduino’s and Raspberry Pi’s.

In the last six months, the company I was working for and I split ways. I used my side contracts to bring in income during this period (plus a descent severance package), but eventually, my wife insisted I get a regular job again (at some point I’ll do a post on the contracting mindset vs the employee mindset). I ended up as the I.T. Lead Instructor and I.T. Manager for a tech college.

A month and a half after I took this job, the corporation that owns the college (and several others) made a shift in their approach. In short, they decided to no longer take on any more on-ground students, and moving all new students to the online university that is part of their portfolio. They made the commitment to support all current students through graduation, which game my position a specific timeline.

During this time, I’ve been waiting for another project I’ve been helping to design to officially start-up. That project is still coming, but there is no specific timeline yet, and my job here ends in a little over two months. Once again, my wife was becoming very uncomfortable with the unknowns coming up.

Here’s where the stars aligned. My mother, who is also a Software Engineer, has been working for a trucking company for many years, helping with devices to reprogram the vehicle computer (modern version of chipping a vehicle). Several years ago, they came out with a device not intended for deals, but for end users. As part of the project, I was able to design and build a web platform to allow updating of the devices.

After the project, a discussion was had on the possibility of bringing me on full time. My mother was told due to history in the company, they did not like to hire family members. Bummer. I really like the project, and the people I worked with.

Flash forward, and a few weeks ago, they ended up letting go one of their developers. A few days ago, my mothers manager had a discussion with her on finding someone that would be able to program on these custom chip devices. She reminded them I could pick it up pretty quick, but they had said no before. Due to my background, my history with the company, timing, and just plain dumb luck, within a day I was brought in for an interview, and offered a job.

As one of my friends put it, part of it was odd skills they needed, but also was the connection to get me in the door. There’s a lot to be said for that. This is where networking is so important. Don’t pass up networking opportunities, because it is much easier to find a job or a project when you already have relationships.

Entertainment Technology Convergence

For those who came to this blog from the I.T. industry, the focus on the entertainment industry may seem a bit odd. What most people that don’t work behind the scene’s in the Live Entertainment industry is that the technologies used have become more and more tightly integrated with an I.T. based backbone.

When the Disney Corporation built Disney’s Animal Kingdom park in the late 90’s, they used a new technology (at the time) by the company Digigram called CobraNet. For the uninitiated, CobraNet was an early Audio Over IP technology that allowed up to 64 audio channels to run over computer network segment.

A few years later, when Disney built Tokyo DisneySeas, they put in a gigabit backplane throughout the park, specifically to handle the standard data as well as CobraNet traffic. This allows Disney to have a central control room, and push out all the audio to speakers from there. The way the technology works, there is a specific few millisecond of latency added at each router, so they are able to calculate the timing to keep everything synchronized to the frame.

Over the years, CobraNet was replaced with CobraNet 2. That technology has lost market share to Dante, as well as several other Audio Over IP technologies.

Around the same time that Audio Over IP was making headway, work was being made in the lighting industry for controlling concert lighting over IP networks. Leading up to the mid-80’s, just about every company that made theatrical dimmers used their own proprietary control system. In the mid 80’s, industry leaders finally got together to define common protocols, so equipment would be interchangeable (and much easier to cable).

Two protocols came out of that first consolidation: AMX192 and DMX512. Obviously, AMX is an Analog based protocol, and DMX is a digital based protocol. Eventually, almost all the theatrical control systems moved over to DMX (especially as programmable moving lights became prevalent in the industry).

Fairly quickly, DMX was being stretched to the limits of its capabilities. In response, companies started coming out with proprietary protocols for running DMX over IP. With time, a handful of protocols started to dominate the industry. Eventually, again, industry leaders came together to define public protocols, in attempt to standardize the industry.

Currently, the leading proprietary protocols are ShowNet, Pathport and Sandnet. The public protocols are ACN, ArtNet and ESP Net. All of these run over IP networks, and can exist over the same fiber connections as the Audio Over IP devices (running on separate VLAN’s).

Imitation, The Highest Form…

As a child, growing up in Southern California, we would go to Disneyland with a certain degree of regularity (being only about an hour away). Even with the somewhat regular schedule of attendance, when I knew I was going to the next morning, I would have great difficulty falling asleep the night before (almost as bad as trying to fall asleep on Christmas Eve).

As I expanded my knowledge of technology, through my adolescence, I began to view the rides, both the new creations, and ones I had been on hundreds of time, with a view of how these creations were created, how the technologies were harnessed to tell the varied stories. It didn’t help that I had a leg up on the basis, being raised in the Movie industry by a Father who did Special Effects professionally (I was introduced to the “Anarchist Cookbook” at an early age – the original – to assist in building explosives for use in a movie).

Between this odd background, and the many years I spent studying music, eventually led me into the live entertainment industry – specifically, lighting, sound, video and rigging for concerts, conventions and special events. In the late nineties, my Father was contracted to add Special Effects to “The Hidden Mine Ride” at a new theme park, “Jungle Land at Mersal Village” in Jeddah, Saudi Arabia (renamed the “Lost Mine”). I ended up being contracted to do the lighting, sound, video integration and show control. Later, I was asked to do lighting, sound and show control throughout the park walkways and a few special features. I’ll probably do a series of posts about this project later.

Several years after completing the installation of Jungle Land, I was hired to design and install theming for a Pirate themed restaurant, “Pirate Island Pizza” in St. George, Utah. I also designed the theming for the second location, though another group was hired to do the A/V installation. Later, when the corporation bought the store back, I had to maintain the cheap, hacked home automation system with cheap Chinese theatrical lighting (the equipment I used was all theatrical and industrial level systems, meant to last for years).

During the design phase of the project, I did many visits to Disneyland, specifically, the “Pirates of the Caribbean” ride. Specifically, I would look to see the lighting and audio techniques the Imagineers used (if you get a chance to go, look back every few minutes, especially if you’re sitting in the front of the book. Pretty soon, everyone will be looking back when you look, to see what you’re looking at!).

I also “borrowed” the concept of the thunderstorm the “Rainforest, Cafe”. I do believe mine read better though. With the audio controller I used, and with my lighting design, I would have the storm start back corner of the restaurant, and roll through to the front. We also created a canon fight between our faux ship, and a “fort” we built.

Unfortunately, neither of the pirate themed restaurants exist any more. They were a lot of fun to design and build (and stretched me quite a bit. I was sitting down with the founder of the Pirate restaurants today, and he showed me a video of a pirate themed restaurant in France that “borrowed” a lot of our design for their restaurant. Their ship wasn’t as tall as ours (forcing the cannon heads to be aimed up, so as not to blast the patrons in the face with smoke), and their lighting design was very rudimentary (some of the lighting looked good, and some quite bad). And the dialog for the pirates is just annoying.

They even used the skull cave entrance to the arcade. It opened up about two years after we opened our first restaurant (and we just found out about it). Well, they do say that imitation is the highest form of flattery. And I do give them credit for integrating live actors with zip lines. It’s just hard to see someone take my artwork. While I was taking someone else’s. Ya, it’s a hypocritical loop. Oh well, just got move on.

Moving to Agile

As I wrote in the last posting about Agile, truly moving to Agile development requires a buy in from company hire ups. In our case, we knew we had to change directions. There were lofty goals ahead of us on what the business was asking for in the platform we were creating. Way more than three engineers could handle.

Our current operation just wasn’t scalable. The founder, who had, among 50 or so other hats, was acting as the product manager and the QA manager. To give full credit, he did start with an idea, and hired contractors to start his vision. He had started long before the Atlassian stack exited, let alone other tools. He had learned to organize his operation through the extensive use of spreadsheets (and he loved the Google stack).

When our new CTO came on, during the testing cycle of last waterfall iteration, he saw the chaos that was our testing scheme. The system had become large enough, and inter-twined enough, that his testing spreadsheet had over 10,000 tests on it. A lot of support engineers, along with us developers spent quite a few late nights running through the tests, to get a release done we were comfortable with.

On top of that, the current platform required a build. The only system that could do the build was on the system of our most senior engineer, who lived in Canada, not the Southern United States. As you can see, getting to done was a monstrous task, and we knew we needed to ramp up the number engineers we had working on the product.

This shows one of the huge strengths of Agile. It’s built for scale. And since as a team, you focus on breaking down the projects into small tasks, accomplished and tested quickly, you eventually get rid of the huge testing cycle (admittedly, getting to that point takes time, but you’re able to shorten what is tested based on what was worked on).

As we were educated on Agile, we were also introduced to the concept of Srum. In a few weeks, after finishing the last release, the CTO started hiring more engineers, and got us working in the Scrum format. Really getting into Scrum took a little bit of time, since along with hiring more Software Engineers, the CTO also had to start building a QA team, as well as a Product Development team.

For those new to Scrum, a Scrum team consists of 3 to 8 Software Developers, a QA Engineer, and a Product Manager. Over time, we came to learn, in our teams, the ideal number of Software Developers was 5.

We were introduced to the concept of breaking projects into a series of “stories”, and weighting the “stories” with a point basis. The point basis is a numerical description of how hard a task is. The idea is, the entire team points the stories, discussing and debating the weight, until a consensus is reached. Once all the stories are pointed, team members choose what they are going to work on over the next iteration, called a sprint.

One of the genius points of Scrum, is that is it supposed to be self-organizing. There is a designated “Scrum Master”, who leads the team, but not from an authoritarian stance. The value of the points are supposed to grow organically (though we did end up adopting a standard hour-value for a point, to make it easier for management to project timelines and efficiency).

Since team members choose what they are going to work on, they are in essence committing to the rest of the team that they will have the tasks completed within the next sprint. The length of the sprint is arbitrary, and our teams chose to make each sprint 2 weeks long. The tasks were not considered complete, until after the QA member of the team had tested each tasks, and product management had accepted the work.

As we were making the evolution to full Agile and Scrum, we broke into two teams: a team specialized to a very unique set of code (which I was on), and the other, larger team, that did more generalized work. The other team investigated build systems (to free up our most Senior Engineer, and to protect the company in case something ever happened to him), and also investigated frameworks, since our code was old enough to be very custom.

One other thing the other team worked on (other than code enhancements) was creating coding standards for each language we worked in. Unfortunately, since all these major enhancements were being done by the other team, while my team was neck deep in new code, we were always playing catch up after the fact on learning these technologies (and never did have a say in the accepted coding standards).

One other change that happened very quickly was moving our development process to the Atlassian stack (even before investigations into the build systems occurred). I was so thankful to get away from all the spreadsheets, and start using a Scrum board. Eventually, as our teams grew out, there was one team that was working on integrations for our front end system that chose to use a Kanban board. This also meant moving away from SVN server (which had served us well for many years), and moved over to Bitbucket (a GIT based system, focused more on private repositories rather than Open Source repositories – also part of the Atlassian stack).

When we first started doing Scrum, our CTO acted as our Scrum Master. Over time, as he was getting spread wider in his responsibilities, those who chose to volunteer to become Scrum Masters were sent off to classes to become Certified Scrum Masters. I was one of those. As our CTO said, not all trainers were of the same value. The one he recommend, which we went to, was a group called “Mountain Goat”. If you are interested in becoming a Scrum Master, I highly recommend this group (I don’t get any kind of kick back for saying that, or linking to their site – I really mean it!).

For those interesting in learning Agile development, here are a few suggested readings:

Learning Agile: Understanding Scrum, XP, Lean, and Kanban

Scrum: The Art of Doing Twice the Work in Half the Time

Scrum Mastery: From Good To Great Servant-Leadership

Hard Things

As part of the journey I’ve taken in self improvement, one of my mentors have a list of hard things to do. The concept is that if you force yourself to do hard things, when life throws curve balls at you, they will seem easy. You can’t do hard things once. It’s a workout, sometimes physical, more often mental. And just like going to the gym, you can’t go once a year for two weeks, and expect to have any long lasting results. You need to create a pattern, a habit, and follow that pattern again and again to see the growth.

There are quite a few hard challenges that involve exercise. Specifically running. Well, that’s out. No that I’m lazy. I used to enjoy running quite a bit. Until I blew out my ankle in a theater rigging accident. Can’t run now. On the exercise front, I have taken the challenge from exercising once to twice a week, to constantly exercising three times a week (I plan to eventually move to five days a week, but really need to build up more endurance to be able to do that. I’ve only been going to the gym consistently at all over the last four months).

One of the other challenges is to create a blog, and write in it at least once a week. I’m combining that with another challenge of writing at least 1,000 words a day for a year. So, sometimes I may post more than once in a day. Maybe I’ll prep several posts to happen in a week. Sometimes, the writing will be private correspondence. I do plan on achieving these two goals.

Another goal I’m looking at is starting a YouTube channel and make a video every day. Well, I already have a YouTube channel (https://www.youtube.com/user/litemizer), though I haven’t done much with it. I’m obviously not afraid of getting in front of the camera. I’m just not sure what subjects I’d cover. Reading the posts in my blog would be pretty boring (both for the me and the audience). Hopefully, I can come up with some ideas for content, so I can follow up with that goal.

Many of these goals are intended to creating a rhythm of doing hard tasks. Some are to feel the elation when goals are completed. Several are both. I’m very interested in seeing where this goes.

Agile Development

A lot of talk has been given in the last 10 years to the concept of Agile Development. Since it’s creation in 2001, it has swept the software engineering industry. I remember first hearing the about it back in 2013. I was working as a Software Engineer as a C# developer. I was getting ready to take some time off, and my manager had mentioned she wanted to investigate Agile development, and incorporating it in our team.

I did a quick search for something on Agile I could read while on vacation. I stumbled on the book, “The Phoenix Project”. While not specifically on Agile, it gives a great basis on flow constraints. It’s an easy read, and really opens up the mind on how to spot bottlenecks in a flow process, and how to alleviate them.

In a lot of ways, this is what Agile development is all about. For years (and even for a lot of companies is still the normal flow), the way we developed was what was know as “Waterfall Development”. You spend a lot of time designing every minute detail of your software, get approvals, go back, refine the design, get more approvals, and finally, start coding. Once you’re done coding, you test, fix, test, fix, blah, blah, blah. Eventually, after several months, you release a finished product. And then you go back, and start designing again.

This flow has several huge draw backs. If there is a need for your company to shift directions, and you’re halfway through the development phase, how do you, as a company, react? Do you drop what the developers and project managers have spent weeks to months designing, and start over? Do you let part of your developers finish what’s been started (making the process even longer)?

From a current industry approach, is releasing software once or twice a year acceptable? Is this maintainable if you’re build a cloud based platform?

These questions, and a million more like them, are why Agile is taking over. Any SAAS platform that is doing Waterfall development will never be able to keep up with their competitors. The concept of CI/CD (Continuous Integration and Continuous Delivery) cannot exist in a Waterfall environment.

When I came back from vacation, my manager did her best to implement Agile. Looking back, she didn’t have the training and understanding to really implement Agile. I give her huge credit for trying. It’s very difficult to move to Agile without the buy off the upper management of a company, and it’s hard to get that buy off if you don’t fully understand the framework. And none of us really did, so we really only integrated a small piece of Agile.

The next company I worked for started out very small. They had been around for quite a few years, and the primary product was starting to get some maturity. I was the third engineer hired at the company, and it was definitely a Waterfall approach. Over the first year and a half I was there, the company saw remarkable growth, which included building out a large dev team. One big issue with Waterfall is that it doesn’t scale well.

As the company grew, the founder was getting spread to thin, and so a CTO was hired. He was well versed in Agile. He came in just as we were going into a debugging session before a release. He watched us struggle with the thousands of tests required to ensure full integration worked seamlessly. As the next iteration began, he began to integrate Agile and Scrum into our operation flow. While it took a while for us, as a dev team, to really get up to steam on the mindset, once we did, the amount of quality work getting completed skyrocketed.

My next post will delve into how we moved from Waterfall to Agile, and some of the hurtles we had to overcome.

New Focus

A while back, I read a great book called “Think and Grow Rich” by Napolean Hill. This great book was written back in 1937, and it’s truths have inspired countless generations. It is a study of the great economic minds of his time, taken over 20 years.

One of the recommendations given in this book is to find proper mentors. Sometimes, this means finding these mentors by studying about them and their lives, if you don’t have the ability to have a one-on-one relationship with the would be mentors.

Through this recommendation, some time ago, I started following John Sonmez, creator of the Simple Programmer blog, and the Bulldog Mindset blog. He has been a great resource of information for developing myself, both as a software engineer, and as person.

One of his recommendations is create a blog to promote myself, which is the purpose of this website. In fact, he has a course specifically on doing this (and a few other courses geared towards software developers) which can be found here.

So, this blog will be about software development, as well as theme park technologies (another passion of mine), and occasionally some tidbits from my past life in the movie industry and live entertainment industry.