Mark Shead – Mark Shead

About Mark Shead

Find more about me on:

Here are my most recent posts

Pair Programming

Pair programming can be a very valuable tool but it is almost always uncomfortable at first. A good portion of that discomfort is because pair programming pushes you to interact and learn from each other in ways that are very effective, but also require a certain amount of vulnerability. This isn’t bad. Pretty much anything that really pushes you to be your best is going to take you outside (or at least to the edge) of your comfort zone.

This post covers some basics for teams who are starting pair programming. It is by no means exhaustive but should provide a good foundation for teams looking to avoid common pitfalls.

Mechanics of Pair Programming

Ideally, pair programming is an activity with two people sitting side by side sharing a computer and talking through the process as they create software. The ability to physically point at the screen and pass the keyboard back and forth minimizes the communication overhead with this type of programming.

The pair should pass the responsibility for driving back and forth. Sometimes it makes sense for the person who isn’t driving to have a computer in front of them. For example, they could use it to lookup the details of an API or some special syntax as it is needed. They should not be sitting there browsing Facebook and checking their email. That defeats the entire purpose of working together.

Remote Pair Programming

Sitting side by side and sharing a computer is ideal, but many teams are distributed, and you may want to pair with someone who isn’t physically in your building. Pair programming using a screen share tool can work. However, it is much more difficult to hand control back and forth. One way around this is to develop in a branch where you can easily push and pull your changes. That way both members of the pair can stay up-to-date on the code and switch back and forth between who is driving.

While many teams do pair programming with voice and screen share, video conferencing software is preferable to just talking on the phone. It is beneficial to see each other, observe body language, etc. Of course, video conferencing isn’t particularly useful if your screen is filled with the code. You’ll need a separate monitor or television screen for the video to make this work well.

There are newer tools that allow for pair programming inside the IDE. For example, Visual Studio Code and Atom are both introducing the capability for two people to work simultaneously on the same code. If you’ve ever used a Google Docs with multiple people at the same time, you will have a pretty good idea of how this looks. You can see each other’s changes in real time.

Regardless of what tool you use, make sure it is fast enough. Trying to pair program with a two-second delay is very painful. If you build your opinion of pair programming on experiences where you are trying to talk in real time while looking at a screen that is two seconds behind your pair, you are likely to conclude that it isn’t worth the effort.

Shared Ownership Of Code

One of the big goals of pair programming is to make sure that the entire team owns the entire code base. There may be sections of the code that different people are more familiar with, but proper pair programming should help make sure that knowledge about every part of the code gets disseminated throughout the team.

We Instead Of You And I

Pair programming is an activity that requires vulnerability. This is easy to remember when you are the one driving and easy to forget when you are not. Even simple things like using the word “we” instead of “you” to point out problems can go a long ways toward making the interactions less threatening. “We” also helps foster a sense of teamwork, a shared responsibility that is vital to work together effectively.

Think Out Loud

Pair programmers are working together as a team. This means you need to talk through what you are thinking as you do it. You can’t just go silent and tear through writing code, hoping that your pair can keep up. It should be a conversation with suggestions and ideas coming from both of you. Thinking out loud means you may say some things that seem rudimentary, but that is fine. You are working together to solve programming problems. The best way to do that is for both of you to know what each other is thinking as you work through it.

Shared Understanding

Both members of the pair should understand what the code is doing. If your pair is questioning whether something is correct, take the time to make sure you both agree it is right. Even if you know it is right; you can’t steamroll over them. Together you will be more effective if you both fully understand why everything works.

This may mean taking a slight detour to explain something your pair may not be familiar with. This is how you work together as a team. You are making an investment in shared understanding that will have returns well beyond your current coding session.

Spreading Knowledge

One of the benefits of pair programming is the way it spreads knowledge throughout the team. Every programmer has a few shortcuts and tricks that make them more effective. Programming together lets both members of the pair learn from each other.

When two people program together, it is very common for them both to learn each other’s favorite keyboard shortcuts and command line tricks. This may sound trivial, but it is amazing how fast these small but meaningful efficiency gains can spread through a team.

I have seen instances where a junior and senior programmer were pairing together. The junior programmer was able to learn a lot of very important lessons about structuring code from the senior member, but it worked both ways. The junior programmer was more familiar with some of the newer features of Java and was able to show the senior programmer how to make some significant improvements to the code.

Alternate Pairs

You can further spread knowledge within the team by switching up pairs on a regular basis. Ideally, you want everyone to have a chance to program with every other team member. Switching up the pairs for each story can be a good strategy.

In effective teams, this tends to happen naturally. If Bob is the expert on Spring Batch and a new story is coming up that will require Spring Batch expertise, Alice may ask if she can work on the story with Bob so she can learn more about it. Teams that have worked like this for even a few months see significant efficiency gains as new expertise and best practices make its way rapidly from team member to team member.

Is Pair Programming Efficient?

When I mention pair programming to management, their first concerned is that a team of eight people working in pairs will only output half as much code. This makes sense if programming is mostly about typing, but it isn’t. Most of the effort in programming is spent thinking. One of the best ways to solve thinking problems is to talk through it with someone else. This is exactly what pair programming does. The time spent typing is insignificant.

That isn’t to say you can’t be inefficient in pair programming. I’ve heard horror stories of developers pairing with someone who simply played with their phone whenever they weren’t at the keyboard. On the other hand, when the developers are both engaged, it is usually a very satisfying and efficient way to work. Often developers comment that it is significantly more intense than programming alone because working with someone else keeps the work focused and moving along.

Take Breaks

When two people are intensely working together it can be easy to skip breaks. Don’t do this. Don’t skip lunch because you think you’ve almost solved a tricky problem together. Getting away from the work for a few minutes gives your brain a chance to solve problems in the subconscious.

Both members of the pair should take breaks at the same time. If both members are comfortable saying, “I think we should take a break now” then they can be done on an ad-hoc basis. With people new to pair programming, it can be better to decide when you are going to take a break up front. Breaks are essential for making progress and if there is a chance that neither person will be comfortable suggesting a break, then determine when you are going to break before you begin programming.

Hygiene

Be aware of the fact that you are going to be working in close proximity to someone and be considerate. You may want to save garlic for days when you aren’t going to be pair programming. Heavy perfume or cologne that smells great to you may give your pair a headache so be thoughtful.

I once did a phone and screen share interview with a developer who was physically at my client’s office. The guy seemed to know his stuff, but after the interview, my clients who were in the office with him didn’t seem very impressed. They weren’t exactly forthcoming because no one wanted to just come out and say that they weren’t comfortable working next to this guy. I don’t know exactly what the issue was, but they threw the keyboard away after he was done using it for the interview.

What is Agile?

Many things get called Agile—especially by people who are selling something. Agile is defined in the Agile Manifesto. The Manifesto makes it clear that Agile isn’t a methodology. It isn’t a specific way of doing software development. It isn’t a framework or a process. In fact, most of the things that are marketed as Agile tend to miss the point of what Agile actually is.

Agile is a set of values and principles.

Much of the discussion around Agile has to do with following different practices, using various methodologies, and even developing with specific tools. For example, while a team may find that having a daily standup is helpful, the standup is only “Agile” to the extent that it is the result of a team following the Agile principles and values.

When you understand this, it is easy to see that Agile is really a collection of beliefs that teams can use for making decisions about how to do the work of developing software. While this means the term Agile gets subjected to a great deal of abuse when people claim that this or that is the way to be Agile, it also means that if you truly understand what Agile is, it is surprisingly flexible. Agile doesn’t make decisions for you. Instead, it gives a foundation for teams to make decisions that result in better software development.

Agile Manifesto

The Agile Manifesto is only 68 words and very simply says that the signers have found that they can develop software better by valuing the items on the left side of the list more than the items on the right side. Below is the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile Principles

In addition to the values of the Manifesto there are 12 principles that support the values. Once again the principles are very general and are less about telling you what to do than they are about giving you the ability to make a good decision in a particular situation.

The principles are:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Decisions

Since Agile is a collection of values and principles, its real worth is in giving people a common foundation for making decisions about the best way to develop software. For example, consider a new project that is in discussions on how to get the requirements from the business owner. The suggested approach is to require that the business owner write down all the requirements and sign off on them before beginning the work. A team that is following Agile would say:

“While that might work, isn’t that inconsistent with our belief that we should value customer collaboration over contract negotiation? And doesn’t it violate our principle that says the developers should be working with the business owners every day? How can we make this decision in a way that is consistent with our values and the principles we follow?”

Or consider a developer who is working on implementing a feature for the business owner. The developer realizes he needs a database to make the feature work. The first idea that comes to mind is to stop work on the feature and build out a robust database layer that will handle the needs of the feature and provide support for other development that will be needed later. If the developer believes in the Agile values and is trying to follow Agile principles, they would think:

“But building out this layer means I will have to delay delivering what the customer can see as valuable software they can use. If I can find a way to build just what is necessary to deliver this feature, it will better align with my principles.”

When you have a team that is following Agile they will be making hundreds of decisions each week in the way described above. That is what it means to be Agile. Making each decision based on the principles and values that the team has decided to follow.

Being Agile

The decision making process matters. You can’t try to short-circuit things by taking decisions made by another team and just blindly doing what they decided to do. Another team may make decisions based on the Agile principles and values and end up with a particular way of doing their work. Simply trying to mimic another team’s actions and practices won’t make your team Agile.

After World War II Melanesian islanders were observed trying to bring cargo planes and their supplies from the sky by mimicking the practices they had seen performed during the war. This included clearing the forest to make a landing strip complete with full size planes made out of straw. They also created structures that mimicked a control tower out of bamboo and had someone sit in it wearing headphones fashioned from coconuts.

It is easy to fall into a similar type of cargo cult mentality when it comes to Agile. The things that are easy to notice in a highly functional Agile team are the practices they are using. But the practices a team uses is the result of following Agile principles and values. It is less important what practice a team happens to be using than why they are using it. In fact, as time goes by, a good Agile team is probably going to change and refine what practices they use.

A team might start with SCRUM and later find that Kanban is a better fit for delivering value to their customers. A team might begin standing up in a daily meeting and later decide it works better for everyone to stay sitting down. Another team might start out using Planning Poker to estimate story size and later do away with story points and simply split stories to where they are somewhere in the same range.

That isn’t to say it is useless to look at practices being used by teams that are performing well, but you can’t go looking for practices to make you Agile. Your principles and values are what will make you Agile. You have to look for practices that support your principles and values. The way you select your practices is what determines whether you are being Agile or not. If a practice is being selected because it looks like a good way to follow Agile principles, it is probably a good place to start. The same practice can work poorly for a team if it is selected for the wrong reason.

So what is Agile?

Agile is a set of values and principles.

How does a team become Agile?

They make their decisions based on Agile values and principles.

The decision-making process is how a team becomes Agile. The values and principles have enough flexibility to allow teams in a wide variety of organizations to develop software in the ways that work best for their particular situation while providing enough direction to help a team continually move toward their full potential.

Why Single Claps in Medium

Medium has an interesting way of voting for content that you like. You can “clap” for content. You can clap once or up to 50 times. If you hold down on the clap icon, it will count its way up to 50. This is an interesting approach to interaction and provides much more data on the back end as to how well people liked a particular piece of content. Of course, now there is the issue of authors asking, “Did you not like my content because you only gave me a single clap?”

I’m not sure what Medium is doing in the background, but I noticed that they do keep track of the number of unique people who clap for something. Between those two metrics they should have the ability to identify how well liked something is. If someone’s personal statistics show that they usually give 50 claps to a piece of content that they like, it would make sense to weight a single clap from them as worth less than someone who only gives a single clap to any piece of content.

Basically, this is what the partner’s program is doing with payments. Every paying member has a certain amount of credit to be distributed. If you only clap for one piece of content then it gets all the credit. If you clap twice for one piece of content and once for 3 other pieces of content, the piece you clapped twice 40% of the credit while each of the others only get 20%. (There may be some more nuances, but that appears to be the basic idea.)

If this same approach is used to weight how well people like content (paying or not) then it doesn’t really matter how many times you clap as long as you make it reflect your own personal relative value for a particular piece of content.

One last thing of note is that there appears to be a problem with clapping for content that is on a custom domain. If you are using a browser that tries to avoid letting other sites track you, you may run into some interesting issues. For example https://medium.freecodecamp.org. If your browser is trying to block external tracking and you go to a post on that domain like this and try to click on the clap button, it reloads the page on the first click. After that, you can click and hold, but the refresh takes me back to the top of the page. This probably depends on how your browser is configured, but it explains why some people don’t know that you can clap more than once. The UI on custom domains may not be working in a way that makes it easy to understand.

My guess is that this is one of the reasons that Medium decided to stop allowing custom domains and it will be interesting to see how it is handled going forward.

State Machines – Basics of Computer Science

(If you like this, you should check out my cartoons on YouTube and my mailing list.)

Computer science is what enables programming, but it is possible to do a lot of programming without understanding the computer science concepts underlying the process of computation. This isn’t always a bad thing. When we program we work at a much higher level of abstraction. When we drive a car, we only concern ourselves with two or three pedals, a gearshift, and a steering wheel. You can safely operate a car without having any clear idea of how it works. However, if you want to operate a car at the very limits of its capabilities, you need to know a lot more about automobiles than just the three pedals, gearshift and steering wheel.

The same is true of programming. Much mundane everyday work that can be accomplished with little or no understanding of computer science. You don’t need to understand computational theory to build a “contact us” form in PHP. However, if you plan to write code that requires serious computation, you are going to need to understand a bit more about how computation works under the hood.

The purpose of this article is to provide some fundamental background for computation. If there is interest I may follow up with some more advanced topics, but right now I want to look at the logic behind one of the simplest abstract computational devices–a finite state machine.

Finite State Machine

A finite state machine is a mathematical abstraction used to design algorithms. In simple terms, a state machine will read a series of inputs. When it reads an input it will switch to a different state. Each state specifies which state to switch for a given input. This sounds complicated but it is really quite simple.

Imagine a device that reads a long piece of paper. For every inch of paper there is a single letter printed on it–either the letter a or the letter b.

As the state machine reads each letter it changes state. Here is a very simple state machine.

The circles are “states” that the machine can be in. The arrows are the transitions. So if you are in state s and read an a you’ll transition to state q. If you read a b, you’ll stay in state s.

So if we start on s and read the paper tape above from left to right, we will read the a and move to state q. Then we’ll read a b and move back. Another b will keep us on s followed by an a which moves us back to the q state. Simple enough, but whats the point?

Well it turns out that you can run a tape through the state machine and once it is done tell something about the sequence of letters by examining the state you end up on. In our simple state machine above, if we end on s, the tape ends with the letter b, if we end on q, the tape ends with the letter a.

This may sound pointless, but there are an awful lot of problems that can be solved with this type of approach. A very simple example would be to determine if a page of HTML contains these tags in this order:

<html>
	<head>
	</head>
	<body>
	</body>
</html>

The state machine can move to state that shows it has read the html tag, loop until it gets to the head tag, loop until it gets to the head close tag, etc. If it successfully makes it to the final state, then you have those particular tags in the right order.

Finite state machines can also be used to represent the mechanics of a parking meter, pop machine, automated gas pump and all kinds of other things.

Deterministic Finite State Machine

The state machines we’ve looked at so far are all deterministic state machines. From any state there is only one transition for any allowed input. In other words there aren’t two paths leading out of a state when you read the letter a. At first this sounds silly to even make this distinction.

What good is a set of decisions if the same input can result in moving to more than one state? You can’t tell a computer, if x==true then execute doSomethingBig or execute doSomethingSmall, can you?

Well you kind of can with a state machine. The output of a state machine is its final state. It goes through all its processing and then the final state is read and then an action is taken. A state machine doesn’t do anything as it moves from state to state. It processes and then when it gets to the end, the state is read and something external triggers the desired action (dispenses a soda can, etc.). This is an important concept when it comes to non-deterministic finite state machines.

Non-deterministic Finite State Machine

Non-deterministic finite state machines are finite state machines where a given input from a particular state can lead to more than one different state. For example, lets say we want to build a finite state machine that can recognize strings of letters that start with a and are then followed by zero or more occurrences of the letter b or zero or more occurrences of the letter c terminated by the next letter of the alphabet. Valid strings would be:

abbbbbbbbbc
abbbc
acccd
acccccd
ac (zero occurrences of b)
ad (zero occurrences of c)

So it will recognize the letter a followed by zero or more of the same letter of b or c followed by the next letter of the alphabet. A very simple way to represent this is with a state machine that looks like the one below, where a final state of t means that the string was accepted and matches the pattern.

Do you see the problem? From starting point s, we don’t know which path to take. If we read the letter a, we don’t know whether to go to the state q or r. There are a few ways to solve this problem. One is by back tracking. You simply take all the possible paths and ignore or back out of the ones where you get stuck.

This is basically how most of the chess playing computers work. They look at all the possibilities and all the possibilities of those possibilities and choose the path that gives them the greatest number of advantages over their opponent.

The other option is to convert the non-deterministic machine into a deterministic machine. One of the interesting attributes of a non-deterministic machine is that there exists an algorithm to turn any non-deterministic machine into a deterministic one. However, it is often much more complicated. Fortunately for us, the example above is only slightly more complicated. In fact this one is simple enough we can transform it into a deterministic machine in our head without the aid of a formal algorithm.

The machine below is a deterministic version of the non-deterministic machine above. In the machine below, a final state of t or v is reached by any string that is accepted by the machine.

The non-deterministic model has four states and six transitions. The deterministic model has 6 states, 10 transitions and two possible final states. That isn’t that much more, but the complexity usually grows exponentially and a moderately sized non-deterministic machine can produce an absolutely huge deterministic machine.

Regular Expression

If you have done any type of programming, you’ve probably encountered regular expressions. Regular expressions and finite state machines are functionally equivalent. Anything you can accept or match with a regular expression can be accepted or matched with a state machine. For example the pattern above could be matched with:

a(b*c|c*d)

Regular expressions and finite state machines also have the same limitations. In particular they both can only match or accept patterns that can be handled with finite memory. So what type of patterns can’t they match? Lets say you want to only match strings of a and b, where there are a number of a’s followed by an equal number of b’s. Or n a’s followed by n b’s where n is some number. Examples would be:

ab
aabb
aaaaaabbbbbb
aaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbb

At first this looks like an easy job for a finite state machine. The problem is that you’ll quickly run out of states or you’ll have to assume an infinite number of states–at which point it is no longer a finite state machine. Lets say you create a finite state machine that can accept up to 20 a’s followed by 20 b’s. That works fine until you get a string of 21 a’s followed by 21 b’s at which point you will need to rewrite your machine to handle a longer string. For any string you can recognize, there is one just a little bit longer that your machine can’t recognize because it runs out of memory.

This is known as the Pumping Lemma which basically says, if your pattern has a section that can be repeated like the one above then the pattern is not regular. In other words neither a regular expression nor a finite state machine can be constructed that will recognize all the strings that do match the pattern.

If you look carefully, you’ll notice that this type of pattern where every a has a matching b, looks very similar to HTML where within any pair of tags you may have any number of other matching pairs of tags. So while you may be able to use a regular expression or finite state machine to recognize if a page of HTML has the html, head and body elements in the correct order, you can’t use a regular expression to tell if an entire HTML page is valid or not because HTML is not a regular pattern.

Turing Machines

So how do you recognize non-regular patterns? There is a theoretical device that is similar to a state machine called a Turing Machine. It is similar to a finite state machine that it has a paper strip that it reads, but a Turing Machine can erase and write on the paper tape. Explaining a Turing Machine will take more space that we have here, but there are a few important points relevant to our discussion of finite state machines and regular expressions.

Turing Machines are computationally complete and anything that can be computed can be computed on a Turing Machine. Since a Turing Machine can write as well as read from the paper tape, it is not limited to a finite number of states. The paper tape can be assumed to be infinite in length. Obviously, actual computers don’t have an infinite amount of memory, but they contain enough memory that you don’t hit the limit for the type of problems they process.

Turing Machines give us an imaginary mechanical device that lets us visualize and understand how the computational process works. It is particularly useful in understanding the limits of computation. If there is interest I’ll do another article on Turing Machines in the future.

Why does this matter?

So whats the point? How is this going to help you create that next PHP form? Regardless of their limitations state machines are a very central concept to computing. In particular, the recognition that for any non-deterministic state machine you can design, there exists a deterministic state machine that does the same thing. This is a very key point because it means you can design your algorithm in whichever way is the easiest to think about. Once you have a proper algorithm, you can convert it into whatever form is most efficient.

The understanding that finite state machines and regular expressions are functionally equivalent opens up some incredibly interesting uses for regular expression engines–particularly when it comes to creating business rules that can be changed without recompiling a system.

A foundation in computer science allows you to take a problem X that you don’t know how to solve and reason, “I don’t know how to solve X, but I do know how to solve Y and I know how to convert a solution for Y into a solution for X. Therefore I now know how to solve X.”

(If you like this article, you might enjoy my YouTube channel where I create an occasional video or cartoon about some aspect of creating software. I also have a mailing list for people who would like an occasional email when I produce something new.)

Eclipse 2017

It took some maneuvering to get out from underneath the clouds, but we ended up with a pretty good view of the 2017 Eclipse from Nebraska.

Photo of eclipse with clouds around it in 2017 — Eclipse 2017