The strengths of small software organizations

With so much stuff going on lately (finishing my thesis, defending it, preparing a long-distance move) I’d neglected to announce that I presented a position paper at the First Workshop on Requirements Engineering for Small Companies. It’s titled “Playing to the strengths of small organizations,” and it is basically a statement regarding what I think are some significant advantages of small software organizations that are often wasted and overlooked by our research community. It’s short and (I hope) worth a read.

One of the topics that came up during the discussion, and that I wish I’d addressed in the paper, is the distinction between small organizations and small teams within large organizations. They are very different kinds of groups, under normal circumstances, but there is a tendency to lump them together. I’ll expand on this later in this blog.

The workshop was held in Essen, Germany, but I attended remotely. It’s the third time I attempt a remote participation to a workshop, and the first time it worked satisfactorily, thanks largely to the efforts of Thorsten Merten. Among the factors that made it work:

  • Thorsten knew I would not be physically present, and made sure he had a computer with good Internet access to be my proxy.
  • During the discussion, I had a video feed of a part of the room, so I could keep track of who was saying what, and of some body language.
  • I had prepared a screencast of the presentation, so in case my connection dropped Thorsten knew to switch to the screencast and carry on from the same slide. The quality of the screencast wasn’t great (at several points I was simply reading or paraphrasing from the paper), but good enough as a Plan B. It still took me a few hours to prepare it. As a result I relaxed from fears of crappy connectivity and just focused on the content.
  • It was a small workshop, which made it easier to have a discussion where everyone could participate.
  • I had already published a paper on the topic of the workshop, which increased the likelihood of other people knowing where I stood on several issues, making it easier to communicate effectively.

Attending remotely wasn’t as good as being physically present, of course. Conversations surely carried on over there once we were finished, and I missed a session. I also missed the main conference, REFSQ, which according to Neil was quite good. On the other hand, I didn’t have to travel to another continent, burning fuel and money to get there, and I didn’t have to struggle with jetlag or travel stress. After two failed attempts of remote participation at the Workshop on Software Research and Climate Change, I was almost ready to give up on this, but it’s now clear to me that it can be made to work well, under the right circumstances.

About Jorge Aranda

I'm currently a Postdoctoral Fellow at the SEGAL and CHISEL labs in the Department of Computer Science of the University of Victoria.
This entry was posted in Academia, Organizations, Software development. Bookmark the permalink.

6 Responses to The strengths of small software organizations

  1. I read the position paper and I found it very interesting. I also perceive that much software engineering research is addressing problems of very large companies, while leaving small ones aside.
    I am wondering why this happens: Do large distributed companies offer “more interesting” problems to solve?
    Probably, the heterogeneity of such small companies makes it very difficult to “model” their behavior and suggest “scientific” solutions that fit them all. As you write in the “Requirements in the wild”‘s slide, small companies are the result of evolutionary adaptation to a specific context, thus “no generalized requirements technique will be suitable for all small companies”.

    However, I think we should try harder to help this “small” 95% of software companies.

    Thank you for the very interesting post.
    Alberto

    • Jorge Aranda says:

      Thanks, Alberto!

      There are several reasons for the focus on larger firms: they pay for research, they have an aura of respectability (or at least of familiarity), and they face some very interesting problems—usability, computational power, compatibility… But that doesn’t mean that they should hog most of our research.

  2. Some related stuff: “When to call a System small?” for social as well as for technical systems: http://bit.ly/cl5pz0

    have fun
    ¦=

  3. Phil Ruse says:

    Interesting post. I myself have moved from part of a small organisation to being part of a small team in a much larger organisation, by virtue of the company being bought out. It’s quite a change! Intrigued to read of remote participation in a workshop. No reason remote interaction shouldn’t work, I now have weekly reports to someone on a different continent, but a workshop pushes that idea along. I guess preparation is the key.

    • Jorge Aranda says:

      Thanks, Phil. I’ve had study participants reporting similar changes once their small organization was bought by a larger one, so yours isn’t an isolated experience.

      Remote interaction works; it’s usually a question of degrees. You lose a lot of stuff when you go remote. Gary and Judith Olson’s “Distance Matters” provides great insights on the reasons for this.

    • Hector says:

      Re: small companies and their patterns of sucess.

      I was also part of a small company that got acquired by a larger one, and as you mentioned the changes are extreme, however the small groups have been able to at least get the bigger groups to hear their arguments on defending their ‘way of work’ which is part of the reason the buyout was executed: the small teams that exercise direct communication and that know each other for years have developed effective work methods that combine effectively. I’ve read also this paper (“Requirements in the wild: How small companies do it “, http://www.cs.toronto.edu/~jaranda/pubs/REintheWild-RE07.pdf) and I agree to some extent on its content.

      No matter their location these small teams know their work and life pattern behaviors and have learned to deliver through and because of them: homophily, long term collaboration, but what changes in the small team acquired by a larger team is that adapting to changes is a key element to success for the small teams as well, as a matter of fact it is one of the best methods to establish a reciprocal relationship to the large corporation that demonstrates that changes in developing methods can be accepted. Productivity after all is a fine balance between keeping core methods while adapting to a larger organization every day.

      The message to be send to the larger corporation coming from the small acquired groups is: Copy success. Do not enforce policies for the sake of control, but for the sake of efficiency and observe and learn from the stories of success across the company.

      Good reading on this topic is this book (http://www.fastcompany.com/magazine/142/switch-how-to-change-things-when-change-is-hard.html) yes I know, software development processes are unique and some of this examples might be unique to their environments, but changes occur in all the areas of our life, I believe that changes can also occur at small software companies while keeping their essence, their core, what made them successful… untouched either when being acquired or when facing a fast growing competitor.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s