Kris Kemper

I was playing a video game the other night and I thought of another characteristic about how to build a successful software development project. I know, relating video games to multi-million dollar software projects may be laughable to some, but bear with me.

I had blogged previously about how to win the game where I discuss the concept of game theory as it applies to software development. I outlined what I considered the highest level considerations, but I wanted to go into some more depth into how you become good at a game.

There is a particular quality to games to determine if you are winning them or not; When the game allows rapid cycles and fast feedback, you can figure out whether or not you can get better at the game. In the case that you aren’t getting better, you probably should not be playing the game, or you should change the game so the player can get better at it.

The last point is important, and one of more difficult considerations. Perhaps that team will never win the game. The only way to discover that is to play the game in cycles. These cycles provide the information needed. In the previous blog post, I outlined that there were 3 important aspects of a game.

1. Knowing how to win the game
2. Being motivated to win the game
3. Having the ability to win the game

This is all fine in theory, but how do you really know whether a team has unified these three considerations?

Back to my analogy to video games. I was playing a racing game, and at first, it seemed like there was little I could do to beat the computer players. The racing tracks were too hard, the computer players were too good. There was too much chance involved. Then, as I continued to play, I became a little better. Energized by the awareness of this, I played more, and got even better. After a while, I beat the game.

How did I know that I would get better? It certainly seemed like I was failing at first. The answer is that there were rapid cycles of practice and feedback. I got information about how I was doing.

How does beating a video game apply to the 3 principles that listed above?

The first is easy; I had to complete levels of the game that incrementally led to my winning the game. I clearly knew what it took to win the game. Each level that I won was not only a discrete step towards winning, but it was a test of my ability to progress to the end goal. I see a parallel here to having stories represent cohesive unit of valuable functionality or features.

The second is also somewhat easy; I wanted to win. I enjoyed playing the game. It was stimulating and rewarding enough for me to continue trying to win. However, I think it’s important to note that a large part of the reason that I maintained motivation was that I knew I was getting better, and I knew that the end goal was achievable. If I can’t win a game, I lose interest. If I were forced to play a game that I felt was losing, I would also lose motivation, even if you were paying me to play the game. This is reminiscent of a project death march.

The third point is perhaps the most relevant to this blog post. There would be no way to know if I was capable of winning the game without short, achievable, and valuable cycles that informed me of my progress. Not all games can be won. If you were to have me play a computerized chess game meant to compete with a chess grand master, I may never win, even if I play for years.

A difficult part of a project is determining if the people of the project have the ability to win the game. There are many reasons why the game is setup such that it can’t be won. It’s not just whether the people involved aren’t capable (wrong skill sets, insufficient experience, etc), it’s often because the structure of the project impedes success and/or the scope is too large.

I have a lot more to say on this topic. I think that the game theory analogy is very applicable to software development, and organizational behavior in general. I think that there is a fundamental project management question; How does one form a group of people to achieve any endeavor? The general answer to this question is applicable to software development as well.

I once worked on a VNC type application, where the purpose was to allow some number of users to share any desktop application to a group of people (part of the allure is that windows applications could be shared to Linux users). The features that were meant to set it apart from the typical desktop sharing application like VNC was that it would enhance collaboration amongst the users.

It was a fun application to write - It had a Java Swing front end with JNI to use portions of the win32 API and X-Windows API, and we wrote a video and audio server to distribute the view of the application and allow the users to talk to each other in on online group phone call while they were using the application.

There was one desired feature that we could not implement. We wanted to allow users to simultaneously enter text, and simultaneously control their own mouse cursor to interact with the application. We were completely blocked on this feature because it goes against a major assumption of all major operating systems - that one user will use the system at a time. For instance, it’s assumed that one window will have focus at a time. It is also assumed that there is only one mouse cursor at a time. There are even more subtle issues that come up, such as there being only one copy and paste buffer.

At the time, I was disappointed, but I didn’t dwell on it too much. I figured that that level of multi-user collaboration would only service a very small niche market, and that it wasn’t so bad that we didn’t have the possibility of better collaboration.

Fast forward to today. I pair program most of the time, and I find myself longing for an environment that would allow me and my pair to collaborate in different ways. It’s standard pair programming, where we both work on the same window, and have to share the same keyboard and mouse input (preferably with 2 mice and 2 keyboards). So what do you do when one person has to check email, or one person decides to research an issue online, or otherwise engage in a task that is not the same as the other pair member? Typically, each person will have a laptop that they can use for these situations, but that causes the person to separate themselves from the primary work environment. Sharing information will have to done by sending an email or putting a file on a shared drive, or having the other person look at information on the laptop’s screen. What about spiking a problem side by side, where each pair tries two similar but different approaches to solving a programming problem? I would prefer to collaborate with someone in the same environment, where we can do some different tasks in parallel, and can share windows, applications, and data in the same desktop environment.

I think that it would be interesting to expand this idea even further. What if an entire team worked in the same environment, on the same desktop? Each person could have a portion of a huge desktop, and people in a team could choose to collaborate with each other in a very fluid fashion by putting their desktop spaces close together. It would be an interesting experiment in collaboration applied to software development.

Even if multiple simultaneous mouse and keyboard input were generally possible in operating systems, there would still likely be a lot of complex concurrency issues for developers, such as making sure that servers bind to different ports and write out to different files. It’s likely that once popular operating systems generally allow the multi-user features I mentioned before, that it would still be preferable to have isolated machines that interact through collaborative software rather then have everyone actually use the same machine.

I’ve seen software that allows sharing of a the mouse and keyboard across machines, and sharing the copy and paste buffer, but the purpose was to allows one person to connect 2 machines and use them like an extended desktop. Perhaps software like this could be tailored for better collaboration for pair programming or developers on a team not pairing.

Conway’s law essentially states that the structure of a software system will reflect the structure of the organization that makes it.

I’ve seen this effect in small companies with little structure and who seem to be constantly “putting out fires.” This is probably the easiest one to point out, but the code base is often highly chaotic and unstructured. The opposite of that is that rigidly structured organizations have rigidly structured code.

I worked on a project once in a large, very hierarchically structured organization. Sure enough, the code base had a hierarchical structure where modules depended on other modules in a way that could almost be put into an organizational chart. Additionally, the company had divisions that interacted on a contractual basis as though they were seperate companies, and that extended to the software teams. Each team would integrate on a software “contract” basis, and it looked bad if one team “broke” that contract.

I remembered this again the other day when another developer was telling me of a manufacturing company that he worked for. He described how data was often processed from one database and stored in another, and at some point, a cron job would start a process that would pick the data up, do something with it, and store the results somewhere else for some other application. It sounded a lot like how a manufacturing plant works.

I’m sure there is a wide variety of reasons why Conway’s law happens, but I see a couple of primary reasons. One is that whatever theory of management a company implements will almost certainly extend to the software development management, as in my example of a hierarchical organization. The manufacturing example is potentially different. In the case of manufacturing software, I think that it could be the domain that results in the structure of both the management and the software. In the first case, the structure of the software was imposed upon it because it suited the management structure, and in the second case, both the management and the software are structured in order to support the business processes that need to happen.

Recently I had to do some unpleasant code cleanup work.

I’m currently working on a legacy database using Hibernate. Along the way, some of the developers decided to generate the mappings for some of the tables instead of writing the mappings only for the columns that they need. The result is that as we reach the release date, we have a bunch of mapped fields that are not used. There were over 800 mapped fields in the code base, and my job was to manually search for references on the those fields and see which ones could be deleted.

I had no desire to spend some number of days tracing the usage of over 800 values in a codebase, so I did some googling on whether a tool is out there that can help me. In particular, I wanted something the would scan the code base, and find usages on all public methods in a code base.

I found a bunch of forums where people debated whether such a tool should exist. I found several tools that will point out unused private methods. There are even tools that generate dependency graphs, which, at some point probably know what methods are getting called and which ones aren’t. However, I did not find anything that would just list unused public methods.

My next idea was that I could write an eclipse plugin. After all, eclipse has the logic built in for finding usages on one method, so it seemed like I should just be able to ask it to give me a syntax tree of some kind that I can traverse, calling that function on all the methods. On the plus side, it looks like eclipse has all the parts that I need and shouldn’t take a lot of time to write. On the downside, I’ve never written an eclipse plugin, and the effort looked nontrivial as a first time effort.

So, I put my head down and turned myself into a usage finding machine for 2 days. It sucked.

If you know of a tool that does this let me know, otherwise, I may take a stab at writing an eclipse plugin that does it.