Mark Schall

Remote vs Distributed

Mon, 05 Nov 2018 21:21:58 +0000

Remote Friendly vs Distributed Teams

It has been shown that companies that support employees to work when and where they want to, can support more diverse workforces. Diverse workforces lead to more productive and higher quality teams which ultimately make more profit. When talking about when and where people can work, I often hear the phrases “Remote Friendly” and “Distributed Teams” used interchangeably. These concepts have different implications and it is important for companies to be clear on what they support in order to have a psychologically safe environment.

Remote Friendly

Remote Friendly is about the ability to work from anywhere, like working from home or a coffee shop. The expectations are often focused on the availability of a person, like being online for quick response communication, such as IM, video chat, or fast email responses. When meetings are scheduled, it’s expected that members will participate in that meeting when it is held.

There are many benefits for being Remote Friendly, here are a few. The biggest benefit is the ability to work when traditionally you’d have to take off time. If people are sick but otherwise able to work, they can avoid spreading colds to other coworkers. If people have an appointment close to home, they can make it for when it works in their work schedule, instead of taking a half day and booking the morning or late afternoon, which are prime appointment times. When there are production issues, communication is critical and having them tested regularly in normal workflows will improve the effectiveness in crisis.

The challenges with Remote Friendly are both people focused and technology. With tools like Google Meet and Slack, team members can stay connected all day as long as they have Internet. Besides tools for communication, you should also be conscious of security of your team members networks, you should research tools like VPNs. Remote Friendly is great to keep work flowing, however when a team member is remote, their only sense of the world is through their computer. Working remotely for a day is easy, but it takes significant effort on everyone to make Remote Friendly successful long term.

Support for remote work is not binary and the range of support is pretty wide, you can’t just purchase a Chromebox and Owl and say you’re done. In the Remote Spectrum, companies can range from not supporting any remote access to being Remote First, where everyone use remote technologies even from the same physical locations. The spectrum includes the ability to working after hours as well as working from anywhere with a internet connection.

Distributed Teams

Distributed Teams is about the ability to work anytime, like working in multiple timezones or just working on your own defined schedule. The expectations are often focused on getting work done. Communication is still very important and there may be an overlap of time zones for real-time communication, but there should be a reliance on asynchronous communication.

The biggest benefit of a Distributed Team is the ability to hire the best people, not just the best people in your area. If your product requires support coverage, having team members spread out across timezones can fill that need possibly without pager-duty schedules. Additionally, high priority and time sensitive work can be executed continuously by asynchronous pairing of timezones, such that someone could pick up where someone stopped.

Distributed Team challenges focus mostly on people taking extra steps to make sure everyone is included in information sharing and decision making. This is why when you foster a practices that support Distributed Teams, you will also increase the inclusion of team members. Additionally there may be challenges with taxes and laws around employing from different countries or states.

“Distributed Teams” are generally “Remote Friendly”, since if you can work anytime, where you work should not be an issue. However there may be work that for security reasons or physical limitations that require working at specific locations.

Remote x Distributed Graph

Detroit Labs

Detroit Labs is Remote Friendly and some of our practices align with Distributed Teams, but we have much to improve in order to better support team members that don’t regularly appear in the office in person. We currently have one full-time remote hire, who moved from Michigan as an employee. We use technology like Slack and Google Meet to keep connected with one another. We use Chromeboxes to integrate Google Meet into our meeting spaces and our meetings default with a remote option. Team members regularly work from home when they need to or when Snowpocalypse strikes Southeast Michigan.

While we strive to create an environment where you can work when you want, our meetings are often “you miss it, you miss the information.” We’ve been good at taking and sharing notes when we intentionally don’t include everyone, but we’re not yet in the habit of documenting information for missing and future team members. We also try to make sure remote team members have the ability for input, but the in-the-room talking can dominate the conversation from time to time.

Conclusion

It is important for companies to be clear about what kind of culture they have and how they are going to supported. Instead of using phrases like “Remote Friendly” and “Distributed Teams”, describe how you will support current and prospective employees be included in their work.

S.M.A.R.T. Goals

Mon, 06 Mar 2017 14:20:50 +0000

Often when we set goals, we aim so far forward we can’t even grasp how we will accomplish them. Most New Years resolutions fail for this reason. When we set a goal like “I want to lose weight” or “I want to get a new job”, we are giving ourselves such a large target we never know exactly when we are finished.

In 1981, George Doran wrote an article “There’s a S.M.A.R.T. way to write management’s goals and objectives” and describes a simple acronym for defining effective objectives for managers. He writes that S.M.A.R.T. stands for

Specific – target a specific area for improvement. Measurable – quantify or at least suggest an indicator of progress. Assignable – specify who will do it. Realistic – state what results can realistically be achieved, given available resources. Time-related – specify when the result(s) can be achieved.

By following these rules about objectives, we narrow the target to the point we can form a few different solutions that will allow us to get to the goal. Now you may set a goal such as “I want to lose 10 pounds in 3 months” or “I want to interview at 4 companies that meet my criteria in the next year.”

Recently I started to question some of the goals my team has been setting for themselves for our Sprint. The goals set were Specific, we set the amount of work we wanted to be done. It was Mensurable, we specified the number of Story Points we wanted to complete. The team Assigned itself for the goal. It was Realistic based on the team’s velocity. It was set to be complete for the two weeks Sprint.

Although the goal was S.M.A.R.T. by Doran’s definition, I started to question it. The goal was setup for us to achieve it and that didn’t sit well for me. Goals should have some chance of failure, they should not be easy wins or else they really are just a chores list for you to do. Additionally I began to realize that from an outside perspective the goal was vague and lacked meaning. There is a good discussion about who the Sprint Goals are for and I will leave that for another day.

What I did begin to realize is that S.M.A.R.T. provides a structure for how you want to define your goals, and that Doran’s definition isn’t the only combination of qualities your goals should have. Instead each letter may represent what is the most important aspect you need to be focused on right now.

S - specific, significant, stretching
M - measurable, meaningful, motivational
A - assignable, attainable, achievable, acceptable, agreed upon
R - realistic, relevant, reasonable, rewarding
T - time-based, timely, tangible, trackable

As you can see, some of these words can represent that same meaning. When choosing your definition of S.M.A.R.T. it is best to choose qualities that do not share the same meaning or your target will still be too large. Such as if you chose Significant, Meaningful, Acceptable, Relevant, and Tangible, you only get one true quality for your goals. Where as if you chose, Stretching, Meaningful, Attainable, Rewarding, and Trackable, you will have five distinct qualities for your goals.

S.M.A.R.T. is a great tool to help begin defining goals for yourself and your team, but you should always be providing yourself with room to fail.

xcenv: Groom your Xcode environment

Mon, 05 Sep 2016 02:04:58 +0000

Two months ago, I started to create xcenv, a tool for grooming your Xcode environment. It is based off the Ruby environment manager rbenv, and works by using version numbers instead. Creating the tool, was really easy, once I recognized that I just had to replace the Ruby logic with Xcode logic in rbenv.

Origin Story

Upgrading your development environment is not so simple when you’re working on real shipping projects. You never know when you have to roll back to an old commit to make a hot-fix or track down a bug, but you don’t want to have to track down what you need to get the project to run. This is similar to my previous post Committing Your Candidate.

For the past 6 months, I’ve been working on an iOS project where we had to upgrade from Xcode 6.4 to Xcode 7.2 and then to Xcode 7.3.1. We wanted to make the change after we shipped the next release because we were just building the Release Candidate stage and didn’t want to introduce the risk. Long story short, we have been having to maintain both Xcodes in our development process for the past 4 months.

One of the biggest problems with maintaining multiple Xcodes, is building on the command line, specially for Jenkins. To solve the problem, we started to commit a file in the branches that pointed Jenkins to the desired Xcode application path. When we start a build, we set the environment variable DEVELOPER_DIR to the contents of the file. The limitations of this solution, is that when we wanted to rename the Xcode application file names, we broke the builds until the file was updated.

How It Works

Xcenv works by inserting a shim into PATH before the real tool would be used. Originally I was hoping just to have to shim xcrun, as it can be used to run every Xcode command line tool desired. However after looking at each file in /usr/bin related to Xcode, I found each is hardcoded with a library related to xcode-select. So to get xcenv to work, I had to shim each tool for Xcode.

Each shim does the same thing, it first figures out what Xcode version you want to use and then sets the DEVELOPER_DIR environment variable and triggers the desired command. The Xcode version is found either by the directory tree, the global version, or just uses the system settings.

Why Not XVM?

A few developers have asked why not base this off the tool RVM and to not start the war over RVM over rbenv, but ultimate decision came based on how RVM, handles changing Ruby versions. RVM alters the cd command in the shell to watch for when it should change the Ruby version. If xcenv, wanted to do this same mechanism, the two tools would not work together well.

Fail Fast

Thu, 10 Sep 2015 21:20:17 +0000

Failure is something humans don’t emphasize from day to day. Winners write the history books. We don’t keep track of the Guinness Book of World Failures or have Hall of Fames for the worst players. We don’t dwell on the failures, because we are taught that there is a right and wrong answer, so only keep track of what you did right.

I’m not sure where I first heard the concept of “Fail Fast”, but it has been stuck with me for some time now. I’ve come to reference the concepts when writing code as well as starting new ideas. Lately I’ve been seeing articles about why people should not try to “Fail Fast” and it’s made me think about just why I believe it is so important to create anything important.

Don’t let the fear of striking out keep you from playing the game. – Babe Ruth

Babe Ruth is well known for being one of the best home run hitters in Baseball, but did you know he has one of the highest records of striking out too. Baseball is an intriguing sport, because a player that fails to hit a ball 70% of the time is considered one of the best players. These professionals are getting payed well to fail a lot.

Since I was in High School and grades started to mean something, I realized my mentality going into a test of project easily determined the outcome. If I went in with confidence, I did great and when I went in with doubts, I’d do poorly.

The word fail doesn’t mean catastrophic situations that cause your company to close it’s doors, but instead a mistake that was all apart of the game.

You’re not moving fast enough, if you’re not failing the build.

An important aspect of Agile development includes the use of automated tools to detect errors before and after changes have been made. These tools allow the team to move quickly and catch any mistakes along the way. Without these tools the team would either learn about mistakes later on or have to move slowly along to prevent them.

It might be weird to think about why race cars have brakes, since we know they have to stop, but wouldn’t it make more sense to lose the weight of the braking system and just drive it better? Race drivers need to make small corrections all the time, sometimes it’s a turn of the wheel and sometimes they need to apply the brakes. These professionals make small mistakes all the time, but it doesn’t prevent them from racing and winning.

It is important to keep moving forward fast, but sometimes it requires using the brakes.

Get Feedback As Soon As Possible

I’ve been on projects that spend six months, a year, or even longer to get a product out the door, and when the project is met by the public, the fan fair is so small it feels like we failed. Afterwards we blame it on the marketing or PR teams for not getting us more attention, when really it just takes time to get people’s attention.

I’ve worked on many teams that have required parity across platforms, yet inevitably there is a feature that requires no work for one platform and the other platform requires mountains to be moved. What’s even worse is after we’ve moved those mountains, it turns out the feature wasn’t really what the customer needed.

You never can be 100% certain that features will be praised or shunned by your customers until the product is shipped. Most major web application teams will ship features incrementally, but desktop and mobile application teams are still stuck in the mindset that they have to ship big updates.

Stop wasting time guessing if you have the perfect product, get it in front of other people and see if they want it.

Don’t Hide Your Mistakes

One approach to handling errors in software development, is to just let the application crash, “Fail fast and loud”. Although it is the worst scenario for the customer, if it’s an unknown error you can do more harm than good if you try to recover. By making it clear that the mistake occurred, it is possible to get the best solution to the customer.

What Happened to MS Office Job Requirement?

Fri, 10 Jul 2015 01:49:31 +0000

I can recall librarians in my schools talking about how important it was to have experience with Microsoft Office experience for your resume, so much that we took quite a bit of time learning a lot of features for Word, Excel and Powerpoint. Today we would all just laugh at a resume that had this called out, because we assume that anyone can put numbers in a table, type a document, or create a slide show (probably full of horrible animations).

However I have noticed a significant number of people that don’t know how to use some of the most important features of these software. They will make tables with calculated averages, but do the math manually, so when it comes time to update the table all the numbers are wrong. Similarly when it comes to creating a large document, they manually enter in a table of contents, page numbers and page breaks.

These little steps that make life so much easier for everyone should be a requirement for working in today’s industries. It’s not necessary for someone to know how to do it on the fly, but they should know that they should be using these features to reduce the time (and therefore cost) to use these tools.

Roman Voting

Mon, 22 Jun 2015 17:39:17 +0000

I recently joined a client’s team that uses a technique they call Roman Voting to make decisions during meetings. In this technique, when a discussion has been going on for a period of time and a decision is needed, someone will call a vote. The person calling the vote will describe what the options are and how to vote for them. In a typical use case, the options are thumbs up for one option, thumbs down for the other, and sideways for abstaining. Occasionally there may be more than two options, so just using a one to x fingers option can be used.

Along with being able to just get a poll of the situation, the client also implements a policy that when you disagree with the majority of the team, you must be able to explain why you feel that way. After they share their side, if they decide to conceded they can, but also anyone else that is now sold opposite can change sides. It is important to time box the discussions or they may go on longer than necessary.

This simple technique with some rules allows decisions to be made in a team of strong opinions easier than just talking until someone gives in. It also allows those that are quiet during meetings have a say, when it is often the case that the loudest person gets their way.

Loomio.org

At Detroit Labs we’re trying out http://loomio.org/ to help drive decisions across the company, which is much harder than just across the team. It works the same way as the in-person technique, where you start a discussion and than make proposals. Unfortunately it doesn’t allow for multiple proposals or the Option A or B format. It is painted as Option A or not Option A which is much different than two options. Overall Loomio is a great tool for remote teams and asynchronous decisions, but I think you lose something from not doing an in-person immediate votes.

Pull Requests + Roman Voting

I enjoy thinking of crazy combinations of processes that could combine and form a really awesome tool and so I am throwing out the idea that Pull Requests (PR) and Code Reviews could be very interesting with the addition of Roman Voting.

For the most part this is the way PRs already work for our team. If someone declines the PR or thinks it is not good enough, their vote can stop the decision and cause a conversation.

However I believe it is ok to abstain from voting from time to time and for that to count as participating but not for or against the change.

10 Lessons a Fraternity Taught Me About Running an Organization

Mon, 11 May 2015 15:10:08 +0000

In the Fall of 2006, I became a brother of the Triangle Fraternity MSU chapter, a Fraternity for Engineering, Architecture and Science. During my time as an active brother, I learned a few lessons that have since applied well to the business world.

Bring a new member in should come with hesitation

It takes months of pledging to become a brother of a fraternity. It first starts with a rush, where people show their interest in joining the group. After rush, the brothers will invite you to become a pledge, give you a pledge pin, and celebrate a new possible member.

During the pledge period, you learn the history and the present of the chapter and national organization. A long the way, you have to prove that you are learning what it means to be a part of the group. You don’t learn the actual secrets of the organization until you are sworn in, because it is a big deal to get a new brother.

Don’t make it too easy to join your company, make new hires learn and prove they have learned the values of the company before proceeding to have the ability to affect those values.

Newcomers need to leave a lasting mark

When I was pledging the pledging class had to do some kind project to improve the chapter house, we chose to tile one of the bathroom floors that had been carpet.

Have new hires take time to improve their organization and surroundings, they start to take ownership and the current employees will show appreciation to them for it.

Secrets, oaths, and handshakes bind people that have never met before

Fraternities are made up of many chapters spread across the world. Each brother had gone through a similar process, with a little tweak between each chapter, to become a brother. They share the same secrets and oaths as each other and can verify themselves with a handshake.

I’ve always felt a bond with every brother I have met, whether it is an alumnus or from another chapter, I know something important we share between us.

The values your organization define are the oaths that each employee should be swearing to when they join. Without knowing anything else about a coworker, you should know that they also believe in the same values as you.

Rules in meetings allow you to get shit done

Most fraternities follow Robert’s Rules of Order during all proceedings. It allows meetings with the entire house involved to proceed efficiently and with courtesy to the fellow brothers. Meetings are the bane of employees, and every website that talks about improving them include purpose and order.

Define rules such as how to call an end to the meeting without letting the facilitator just keep going or simple time limits for a discussion, they will dramatically improve the morale of a meeting.

A single decent is as important as a unified approval

Not every decision is going to be unanimous and it is important to distinguish those from others. Most fraternities follow the practice of blackballing, in which an anonymous vote is casted using white and black balls.

Blackballing is used primarily for voting to accept someone into the group, whether it is rushing or a pledge going to become a brother. These votes are particularly important, and therefore just one vote can make the decision. Sometimes a single black ball, means that more discussion should take place and a second vote is taken to see if minds have changed.

Bringing someone into the organization is a big deal, they are not just another number, they are going to be with you the rest of your life.

Remove people that are bringing the group down

One of the worst days in the fraternity was when we decided to kick a brother out for not being a good brother. It shook us up big time, but it was critical to get him out of the group, because he was setting precedents for future brothers to act that way.

Getting rid of people is tough, but it is important to make sure we hold the values of the group higher than those in the group.

Helping others will make them want to join you

At MSU, the chapter of Triangle holds a 3 day event for incoming freshmen engineers to give a guiding hand to what to expect in college. It also allows them to beat their fellow classmates to move in, missing out on all the hell that is move-in day. We would make sure they were oriented with the campus and also allow them to bond with some new people.

The other effect it has, is that it shows off how great the fraternity is to incoming males. By helping them get orientated, showing our values, and just having fun we were able to get them to rush in the Fall.

Go out and share your knowledge at user groups and college campuses. People treat teachers as experts and want to learn more from them.

Don’t forget to have fun

Of course fraternities are notorious for their parties and I couldn’t write this post without saying that you need to have fun, but it is important that fun is not just by yourself or with just a handful of the other members. Sometimes we’d throw parties that were just for us and other times we’d invite everyone we could find.

The organization needs to make time for everyone to come together and have fun. No alcohol is needed to have fun, just a great atmosphere and lots of people.

Marketing is key to a successful launch

As I thought about a fraternity as a business, I was wondering what would the product or server that business would sell. Our fraternity would sell cups for the beer at parties, mostly to recoup the cost of the first keg and to keep the new ones coming. There were times that we wanted to have a party and no one would show up and sometimes we’d have to turn people away. The main difference between those parties was who we sent out to get people to come.

When launching a new product, make sure there is enough buzz around it and the one pushing it really believes in it too.

Agile and Beyond 2015

Tue, 05 May 2015 16:06:43 +0000

Agile and Beyond had it’s 6th conference on April 30 and May 1 of 2015 and I was lucky to get to go and learn some “new to me” things. I recommend that

I will write more about each topic in later posts but I did want to give a small summary for each presentation I was able to attend.

Leaders at All Levels

Esther Derby opened the conference with a great keynote, that discussed a change from the traditional levels of organizations Strategy, Direction and Coordination, and Performers to Steering, Enabling, and Doing. She then broke it down by three categories of responsibility of leaders; Clarity, Conditions, Constraints.

Leadership is the ability to enhance the environment so that everyone is empowered to contribute creatively to solving problems – Gerald M. Weinberg

Clarity defines what you are working on, how it fits into the bigger picture, and who the customer is. Workers can’t make great products for customers if they can’t get the necessary information.

Conditions are the means for the people to do their work and the support from the organization to do the work. If the organization does not support the workers to be great, they will stay mediocre.

Constraints tell people what they should and should not do and define the boundaries of autonomy. Too rigid of constraints becomes too regulated and routine, where as too much enabling can lead to chaos.

Organizations should prioritize “coherence over consistency”. What works for one person or team may be too much or too little for another group.

The original purpose of a hierarchy is always to help its originating subsystems do their jobs better. - Donella h. Meadows

How Crayons & Post-its Can Alleviate Data Distress and Object Obscurity

Carol Treat Morton and Samah Majadla ran a workshop to show how simple tools like Crayons & Post-its can be used to focus the project’s attention and layout an object map that everyone can understand.

The workshop focused around two real users that were trying to pay for their parking at a meter system. They provided us with some footage of two users trying to pay for parking with a mix result of success.

The first technique they taught was to take one of the users actions and break it down into individual steps on Post-its and then layout in a timeline. This allows you to easily see and identify the pain points of the process for the user.

Then based on the constraints of the client, you can limit the scope of the work to only things that can be changed. In the workshop, the client would only allow us to change the software, because changing hardware would be too costly. This allowed us to focus our attention just to a specific part of the workflow, and ignore the problem areas that dealt with hardware.

Finally they then taught us how to take the action based workflow cards and turn them into object’s that represented the scene. These objects become reference points for the entire team and a common language for talking about the problem.

Overall these techniques were really helpful for me to visualize the problem and made it fun. Although we used markers instead of actual crayons, the big point is to move away from black and white and use color, because it can be fun and attention grabbing.

Putting the D&D in TDD

Guy Royse talked about Katas and how the traditional bowling, credit card validation and Conway’s Game Of Life don’t always push developers to test all their muscles.

The Kata he introduced to everyone is called the Evercraft Kata, in which you work in pairs to ping-pong TDD your way to make a Dungeons and Dragons system.

Although I didn’t necessarily learn anything new for TDD, I did affirm to myself that I do understand it. Also I was able to pair up with some college seniors and help teach them TDD. With the luck of a percent roll, I was able to win a Pound-O-Dice

Agile is for Wimps: Top-Level Software Development in the 21st Century

Alistair Cockburn gave the second keynote of the conference and sadly I only saw the tail end of the talk. Alistair points out that the Agile Manifesto can lead to wimps with lack of deadlines and contracts, but if we go back to the heart of Agile we will deliver what our customers want.

In his talk, Alistair talks about the three stages of a feature or project as the learning stage, the value stage, and the tail stage. In the learning stage you are not delivering much but gathering all the necessary information. In the value stage you are delivering quite a bit in a short amount of time. In the tail stage value delivery starts to slow down.

Sometimes it may seem that you can’t ship without the full feature, but if you “trim the tail” and ship, you will be delivering high value in a short amount of time. Additionally If you break down the features into these stages, you can prioritize them to deliver more value over time, instead of focusing on one feature at a time.

Gamifying Retrospectives for Distributed Teams

Dana Pylayeva gave a workshop about running retrospectives for distributed teams. Each table chose to be a different city around the world, and we retroed the first day of the conference and then using some simple technology, we were going to be able to simulate being distributed across the world.

Trust drops instantly when teams are not co-located.

Although the workshop ran out of time, I did learn a few “new to me” techniques. One technique was to use Story Cubes to help build a story of what happened for the portion of time being retro. Another technique used a timeline to layout what happened, which like the workflow workshop, can help visualize when and where things went wrong or right.

The big thing I realized after the workshop, is that I have been in many retros where the feelings are the first thing to come out, but as Dana points out at the beginning of retro we should be focusing on data and not feelings. I think this is why it can be really hard for some people to discuss hard topics at retrospectives.

Esther Derby, writer of Agile Restrospective sat at our table and shared with us how she used to use fortune cookies to get her team to share what happened that week.

Talent Development 3.0

Matt Barcomb and Rachel Howard gave a really awesome presentation about lifecycle of talent in organizations. The stages of talent are Courting, Auditioning, Growing, Connecting, and Leaping.

Courting is about how you find new great talent. You should always be hiring, by sending the right people out in the community and having conversations with new and different people. Your already great talent can weed out the bad talent faster than a talent scout.

Auditioning is about how you validate the new talent. Use take home or all day projects to push them to their limits and see that they are perfect for your team.

Growing is about keeping your talent great. Stop trying to measure their performance and start measuring their growth. You should be enabling your coworkers to learn and achieve more than when they first arrived.

Connecting is about getting your talent to improve the community. Whether it is the organization or external communities, getting your talent to connect will show how awesome your group really is.

Leaping is about letting go of your talent. You should be building a conduit for talent to constantly develop and when they reach the point where they can’t go any further in your organization they should be able to leave. By building this talent pipeline, the organization becomes resilient and capable of losing anyone in the organization.

Building Software Craftsmen

Steve Ropa gave an enlightening talk about how to train new developers into Craftsmen.

In his talk, he describes an apprenticeship that lasts from 3 to 6 months, in which they learn multiple languages, work in groups, and pair constantly with Journeymen and Masters. He talks about how our universities are failing us and how we can take charge and make developers ourselves.

This talk rang home really well for me, because at Detroit Labs we have an apprenticeship program, that has some of these components but I don’t think it has all of them.

Before I went to this talk, I had wanted to write a post about the idea of treating new programmers like old time apprentices or like electrical apprentices, and this talk revived that idea even more.

Shifting value into high gear

Mike Edwards shares his heartfelt story of how after his dog passed away while he was on a trip, a WestJet employee gave him a hug and took the time to hold an earlier flight to get him onboard and on his way home. This was a “Wow” moment for him. Most companies give us some value, but most don’t wow us.

Mike talks about how we need to be more connected and have autonomy in order to wow our customers. Traditional hierarchy, has the customers representatives on top, followed by some management, and then with the workers. Mike suggests we change it such that the workers are connected with the customers and the management enable the workers to best solve the customers problems.

In the case of WestJet, all the employees are considered owners of the company and so they have the ability to go above and beyond to take care of the customer, even if that means getting them on a competitors airline because of delays or cancellations. By trusting your employees to do the right thing, they will go beyond the required steps to make sure people are treated well.

There’s No I in Team, But Should There Be?

Diane Zajac-Woodie ran a panel of some really great speakers about the topic of Generalist and Specialists. I was hoping for a different talk than what it was, but I did get a few great points out of it.

Most people have a pi shape, with more than one specialty, a specialist just happens to have a much narrower top than a generalist. As you zoom out of a specialists T-shape it becomes more like an I or single line, where as the Generalists stays as a T.

In one of the examples given, one team decided to force all the team members to work on each aspect of the project, testing, development, business analysts, etc. In the end, everyone loved id and creates an awesome product, however they had to force in on the team and they did lose people that didn’t want work that way.

I asked the question, “Can you teach generalist, and if so how?”, in which the answer didn’t necessarily answer my question but did give me some great insight. If a person wants to be a generalist, they are going to have to learn the basics, but they don’t have to go too far into the advance or expert levels of the field. In order to teach generalist, specialists need to be present to layout some heuristics, so that the generalists don’t need to dive so far down to learn the details of every solution.

Handling interruptions during sprints

Sam Nadarajan presented a case study of what happened to his team when dealing with support cases for their product. Sam works on a project where they are shipping new releases every month and support the current production application being used.

He talks about how originally they would just add the support tickets to the same list that was being used to pull new tasks, but it grew out of hand and fixes weren’t being made in a timely fashion. They then divide the boards in two, and made one Kanban board that had the support cases and one Scrum board that had the new features, but still the team only focused on the Scrum board, because that is where all the conversation fell around.

Eventually they decided to rotate a developer each release onto the job of Ops and as problems came in that person would take on that task. When there were no support tickets left, they would be able to take time to refactor and improve the current features. Additionally as problems came up that the person on Ops was unable to solve, the team would swarm around the problem and share the knowledge.

As much as I think you should be able to have the whole team be on support and work on new tasks all the time, having a system like this in place makes for a fair environment and helps break down silos.

Regular Expressions

Mon, 27 Apr 2015 19:04:39 +0000

While working on a Hubot script with some other developers, I had heard one of the new developers explain that they didn’t understand regular expressions. So on Thursday April 23rd 2015, I gave a Lunch and Learn presentation.

The slides can be found at http://www.maschall.com/presentations/regex.html

The Real Hungarian Notation

Fri, 17 Apr 2015 20:33:25 +0000

Hungarian notation has gotten a bad rap because of a specific implementation that was spread or forced upon the industry for many years. Even with so much negative publicity, the principles are still present in today’s clean code.

Naming Conventions

One of the hardest problems developers face on a day to day basis, is how to name variables and functions. It’s crucial to name these well, because:

you’re going to be using these names over and over
someone else is going to need to know what that name means
it needs to be consistent with other variables

Time spent thinking of a name could be better applied to solving the problem. I follow the rule, if you can’t think of a name, put down “bob” and come back to it after you have more context.

Naming conventions, like Hungarian notation, provide a set of guidelines that when implemented by the team, will allow developers to create consistent names for variables and functions.

Hungarian Notation

Dr. Charles Simonyi, one of Microsoft’s Chief Architect, introduced a naming convention that prefixed the functional type to the identifier. The original implementations, used very short hand prefixes that made the variables look like they were another language, and soon became called Hungarain notation.

In the paper, Dr. Simonyi used the word “type” to describe a shared common functionality for variables. They are very similar to what we think of classes, but they are not identical. These types are not at the compiler level like we think of classes, they are at a programmer level where things can be gray.

The point is that “integers” x and y are not of the same type if Position (x,y) is legal but Position (y,x) is nonsensical.

My first thoughts when reading this line, was why didn’t they just use a Point class so the confusion is dead, but there is still the problem of how we get the values into Point. If you think of the constructor Point(x, y), it has become so standard that the first value is always x and the second is y, but it’s the consistent naming of those paramters that make that so.

An alternative and full-proof solution would be to have Point() constructor and setX and setY methods on the class. This keeps everything compiler freindly and explicit, however it is too tedious to use for just creating a simple point.

rowFirst: row is the type; First is the qualifier

The idea of row and column types, is proof to me that the idea behind Hungarian notation deserves a better reception. While it is likely that these are integers, naming them row and column helps enforce specific rules dRow = rowLast - columnFirst makes no sense.

Where It All Went Wrong

As I pointed out above, the term “type” and concept of “class” are often interchanged with one another, so it wasn’t long before lazyness kicked in and developers started mixing the two together. Now all strings started with “str” and instead of “un” and “pw” for username and password, it becomes strUsername and strPassword. Prefixing a variable with the an identifier of the class it represents, does technically follow the notation, but it fails to improve the readability of the code.

Before we had IDEs that could think ahead of our typing and suggest names for us, typing long names felt really hard, so “row” became “rw”, “string” became “str”, “pointer” was shorten to “p”. There were so many different mappings of shorthand types, noone wanted to add more to the list and kept it just the same.

Clean Code

There is a huge push in the community to produce Clean Code, and a big emphasis on names. It is stressed that names are self-explanitory rather than having to know a specific charachter mapping of types.

Using the rowFirst example, today most developers would write firstRow, so that it reads the same as if you were just writing a sentence. The Hungarian notation paper, writes that the formula for names is < prefix > < base type > < qualifier >, and we have now changed our names to follow < qualifier > < base type >.

An example I have seen today is: Paint innerCirclePaint = new Paint(), where the type is placed at the end of the variable name. It is ironic that quite a few developers would prefer this naming, while bashing Hungarian for specifying the type in the prefix.

One Practice To Bring Back/Keep

In the most typical Hungarian notation implementation, variables that are members of a class are prefixed with the letter “m_”. Some implementations use “m” or “_”, but they represent the same concept, this value represents the state of the object.

There are so many bugs that I have found in my career that have resulted on the misuse of a field variable or the overuse of state on an object. The worst offenders, on average, are booleans and they are the biggest code smells for me.

Outside of an IDE, like the code review page for a Github Pull Request, it is very hard to see what variable are members and which ones are local. If we went back to prefixing our variables, with “m”, “_”, or just “this.” ([insert instance reference for your language]), it would improve the process of code reviews and thus maintain great code.

Conclusion

Readability, consistency and memorability are key properties of great names in code. Naming conventions provide guidlines to team members on how to maintain the same level of great names in our projects. The reason that Hungarian notation was so wide spread (and gets the most flack), is that it was written down so that it could be easily brought into a project and it was an unbiased source of truth for developers.

Dr. Simonyi took a chance and presented what he thought were a good set of rules to follow, and whether or not people followed them because they thought they were great or the company forced it on them, it created code that was consistent not just across the company but across the world.