Cowboys, Westerns and Making Software

American pop-culture has some absolute fixtures that have survived from the late 1800’s straight through today. They can be found in books, radio shows (now TV and movies) and their influence can be seen outside of pop-culture and in other, sometimes surprising, places. 

There is a repeated myth of the “lone cowboy” who rides in and saves the day - the one person who shows up and sets things right. From the “dime novels” glorifying the “wild west” through the Lone Ranger shows and movies and the mass-produced westerns of the 1930’s and ‘40’s. You can still see them in such films as Pale Rider. While that is getting rather dated now, it was made in 1985, there are other examples based on the same model. For example, all the “Die Hard” movies or the “Taken” films.

Of all of these, there is one thing that can be said: They are myth. The lone cowboy in the west usually did not live long. The rough and tumble gangs riding into town to rob banks often ran into people not afraid of them. The clearest example is the James-Younger Gang’s raid on Northfield, Minnesota in 1876. That one had Jessie James and his gang run smack into a town full of US Army veterans from the Civil War who were not afraid of robbers, no matter how famous they were.

There is one thing in these movies that is close to accurate. In Pale Rider, the last of the “man with no name” movies, the “Preacher” is a ghost. He’s already dead.
​
The overlooked portion of these stories is this: the “lone cowboy” saving the day often does not act alone. There is always someone helping him, gathering information, finding things out needed to solve the problem or simply “backing him up” in the final climactic scene. 

In The Quick and the Dead, the 1995 movie with Sharon Stone, Gene Hackman, Russel Crowe and a remarkably young Le DeCaprio, the “mysterious stranger” is a woman. She draws on information from Russel Crowe, and others to survive, then defeat Gene Hackman in the final fight. 

Why am I talking about Westerns? There are lessons here for us in software. 

The Lone Developer 

The “lone developer” working in a cave, basement, or closet of a workspace, away from everyone, doing fantastic work and cranking out perfect software is as much a myth as the lone cowboy of the “old west” is. 
There may be individuals working this way, however, they are often hobbyists or working a side hustle. Of course, “perfect software” is also a myth but we’re going to look at making software at the moment.
Since I began making software professionally, I have met one person who claimed to work “best” that way. That was many years ago. Looking back, I may have claimed that at one time as well.

Both he and I were wrong. 

It is exceptionally difficult to make software without interacting with other people. It is impossible to make good software without other people helping us. 

What does that mean? 

To begin with, most software development organizations, even in startups I’ve worked with, have some level of coding styles and standards everyone is expected to follow. These can be very simple, such as “do those things like this.” They can also be more complex, like, “don’t write the same thing more than once; if code can be reused, reuse it; if code can have parameters added to make it more reusable, add them.”

While some folks shun the question of spacing or alignment and don’t worry if the nested conditional statements are indented two or three spaces, others will insist that things must be done precisely THIS way.

I never got worked up about them. The expected behaviors were presented and explained, and that was that. As long as I knew what the rules for that shop was, that was fine with me. 

If you have ever been in that situation, then you’ve seen the same type of thing. To continue the metaphor of the “cowboy,” those were the rules of the town. The stranger arrives, looking to fit in if possible and stay a while, or settle down there. The Sheriff or someone else in the town explains the basics of the rules and how the town functions.If you’re OK with that, you can stay. If you would rather not fit in and conform, then by all means, go.

It is the basic structure of all of society. 

These are the expected behaviors. If you follow those norms, we (the rest of the group) can and will help you become established and be successful. Not following those behaviors will not lead to success.

And Software
The point of software is to solve a problem someone has. If it is commercial software, the problem might be a common one that many people in many organizations have. If it is internally developed, then it is meeting a specific need within a single company.

The nature of the social norms will vary depending on the purpose, and problem, the software is to address. These norms can vary widely. They might include:

• Who gathers and compiles the description of the problem to be addressed;
• Who describes the expected behavior of the solution;
• Who maps the interactions with existing software and systems;
• Who outlines the solution from a technical perspective;
• Who executes the development of the solution;
• Who reviews the solution for basic adherence to the norms of the shop;
• Who exercises the solution against the expected behavior and problem;
• Who reviews everything for correctness and adherence to the expected standards and styles.

This list might be seen as intrusive to some people. And yet, they are common enough in many shops. When I ask about these at an engagement, I’m surprised at the number of times the response is “We don’t do anything like that.” 

That often explains the list of bugs and problems encountered by people using the software. 

I get that these are not “code standards” or some other technical concept. Instead, they are something far more difficult.

They describe social interactions. They are part of describing how a software organization operates as a social organism. There must be interactions with non-technical people, those whose problems the software is to solve. There must be interactions with technical people, people needed to make the software work and behave efficiently, if not correctly. There must be interactions with people who are a mix of technical and non-technical. 

​How these work can vary and take other things to make possible. Those things will be discussed later.