Criteria to fix a bug

Ok. So this may seem stupid, but I was pouring over a list of defects in our product backlog the other day and I started thinking "How do we really decide if a bug should be fixed?" Everybody talks about severity, and I suppose that is the most important factor in most cases; but that's not the only factor.

It dawned on me that there is a simple equation to represent the value of fixing a bug: The value of fixing a bug is the ratio of the impact of the bug to the cost of fixing the bug.

valueOfFixingBug = impactOfBug / costToFixBug

The higher the impact in relation to the cost, the more value there is in fixing the bug.

It doesn't seem like I'm saying anything novel, but in all my years of software development it just seems like people don't really think about *impact* -- they think about *severity* -- and the cost part of the equation doesn't get talked about all that much. Maybe because clients don't consume themselves too much thinking about the cost of defects, because they get them for "free", not considering things like opportunity cost.

Let me try to make this a bit more useful...

The impact of a bug is *not* the same thing as severity -- at least not the way most people define it. Here are the things I would consider the factors of impact:

1. When it happens, how bad is it?
2. How often does it happen?
3. Who does it happen to?

These are the things that, as they increase in magnitude, should sway you in favor of fixing a bug or prioritizing higher than other work.

The first item in the list ("how bad is it?") is what most people call "severity". This is a concept that exists in most bug-tracking tools, expressed as a number (1-5) or a word that conveys the severity. And we use phrases like "This is a sev 1" when we talk about them.

The "how often" and "who" parts of impact are not discussed much. It might be useful to combine them with the severity to come up with an "impact".

And so of course we can do a similar expansion of the equation's denominator (costToFixBug). Here are the things I would consider the factors in cost:

1. The cost to determine the source of the problem.
2. The cost to implement a fix.
3. The risk of breaking something else.

These are the things that, as they increase in magnitude, should sway you against fixing a bug or prioritizing it lower than other work.

I thought it was mildly interesting to think about this problem in this way.

Testing Mobile Web Applications

For the November issue of LogiGear Magazine I wrote an article highlighting What Matters in Mobile Testing, a quick set of points to consider if you find yourself needing to test a mobile web application or native mobile application, but perhaps you come from a background as a tester of traditional web applications.

VersionOne vs. PivotalTracker

VersionOne and PivotalTracker are two competing Agile management tools. I've used both. Here's a quick comparison:

Arguments in favor of VersionOne

1. There is a large community of users for VersionOne with lots of support, whereas PivotalTracker is relatively new.
2. VersionOne is a feature-rich enterprise-capable tool, whereas PivotalTracker is a purposely feature-strict "opinionated" tool.
3. VersionOne can be hosted on your own servers or in the cloud, whereas PivotalTracker is only hosted in the cloud.

Arguments in favor of PivotalTracker

1. PivotalTracker is easy to use and has a slick interface, whereas VersionOne is a (more) complex tool.
2. PivotalTracker is free, whereas VersionOne is not (except for the 10-user "Team" version).
3. PivotalTracker enforces Agile best practices by limiting your flexibility, whereas VersionOne is flexible to the point of (arguably) allowing bad practices.

Loosely Coupled Highly Cohesive Teams

A while back I blogged on telecommuting. I want to apply my argument against physical separation of staff to a global organization.

Teams or individuals who are physically separated from other team members, regardless of whether or not you call it "telecommuting", suffer from the same communication problems.

Here are some givens:

1) Communication is the #1 cause of software project failure.

2) Physically separated teams are often a business reality.

3) Physical separation leads to communication problems.

I think it is safe to say that physical separation is something that has to be overcome, so if you can avoid it, you should avoid it. Having said that, many companies are global and cannot avoid it, so let me put this another way: Don't be cavalier about the cost of physical separation, and design your organization in such a way as to minimize the risk of it.

So, if you do have physically separated teams, how can you deal with it? There are many ways. The one I want to talk about is called "loose coupling".

In software design (and hardware design, and product design), most people are familiar with the concept of loose coupling and high cohesion. Whether or not they employ the concept is another story. When it comes to organizational design, the same concept is valid, but my experience has been that decision makers don't apply the concept; and they should.

It is better for each physically separated team to own one or more of a set of loosely-coupled "things" (unit of work) in their entirety. In other words, for any given unit of work, the product ownership, project management, development, and testing should all be co-located.

What you should not do, without serious business justification, is take a unit of work and split its core functions among people in physically separated locations. A classic mistake, for example, is to do development in one location and the testing in a different location, without understanding the true cost. Another mistake is to put half the development team in one city and the other half in another, or to put the product owner in one location and the development team in another; and to not understand the ramifications.

What I often see is very shallow analysis -- E.g. "Labor cost for testing is $x/hr cheaper in country Y, therefore we will do testing there"; or "I have a team of developers available in another location who can help you, so we should use them and we'll get the project done quicker because they are available now". Splitting resources across geographic boundaries, while not adhering to the principle of loose coupling and high cohesion, it seems to me, increases the communication overhead in some unpleasant non-linear fashion. Re-working my labor-cost example to be loosely coupled and highly cohesive, I think it would be better to say "Labor cost is $x/hr cheaper in country Y. We have a module that fits their skill profile (i.e. they have the ability to do it). Let's have them create (and test, and deliver) that module."

Recent advances in the state of software development practice, which advocate things such as co-location, and emphasize team cohesion, and stipulate that testing is a development activity to be owned by "the team", support what I am saying.

Open-plan offices make workers sick?

Joel Sposky, whose Joel On Software is probably my favorite blog on software development and management, is (among other things) famously against open-plan office space. One of Joel's recent posts points to an Australian news.com article, whose opening line is this: "THE evidence is overwhelming - working in an open plan office is bad for your health."

I also want to point out, for what it's worth, that private office space is a main tenet of the now classic Peopleware.

I'm in favor of open-plan offices, and I've previously blogged about this. I'm up against some very reputable opinions. Photographs such as Joel included in his post evoke images of Taylorism, which for me is the antithesis of what modern open-plan offices should be all about. It's frustrating to see people paint open-plan offices in that way.

If my own experiences didn't tell me that an open office space is the best environment for software development, I'd agree with those that say private office space is the best. I've worked in a private office space (for seven years), and it was really good. I've also worked in a cubicle environment, and I probably don't have to convince many of you that it is the worst.

For an open-plan office to work, it has to be done right. Unfortunately, it is hard to do it right.

I'm willing to bet that most businesses that implement open-plan offices don't do it right, for many reasons, among them being that those who control the design of work spaces tend to be the same type of people who claimed cubicles were the answer. They have no idea the importance of creating a great place to work and collaborate.

All of this discussion is starting to make me think that private offices are the way to go. Private offices are a good alternative, they are easier for people to appreciate, and their benefits are harder to bastardize.

Telecommuting is a bad idea

If you have read my recent blog posts, you have undoubtedly noticed a pattern; i.e. I talk a lot about how software development is a highly collaborative activity; and we all (should) know by now that poor communication is the major contributing factor to project failure. So... stop doing things that detract from effective communication and collaboration. Permanent or frequent telecommuting is one of those things.

I'm mostly refering to the following scenario: You are allowed to regularly telecommute but could otherwise work with your peers in a local office. I'm not referring to scenarios where occasional or permanent telecommuting is ok, such as for reasons of illness or scarcity of talent.

A few years back, I telecommuted full-time for a whole year. I was a software tester at the time, embedded in a software development team. The company was local and was a 20-minute commute for me. There were many facets that were personally beneficial to me: an ability to set a flexible schedule, to not have to drive to work, and to attend to my daughter on demand; but the reality was that the business was not benefiting. I remain convinced that it is a bad idea.

Why to Work for a Large Company

A while back I posted Why to Work for a Small Company. It is only fair that I offer the other perspective. See if you can tell which one is my preference.

Generally speaking, based on my experience, work in software development for a large company if you value...

Reputation

There is a certain prestige that comes with working for a company whose name is recognized and respected. This could open doors to future employment, or to speaking engagements, etc.

Stability

Large companies tend to be more financially stable than small companies. If you look at statistics on business failure rates, if you work for a small company, you have about 50/50 chance of losing your job to business failure within 5 years of start-up.

Specialization

Large companies tend to silo their employees, which means you will likely work within a very narrow domain and set of responsibilities. This is a good thing if what you are after is depth of knowledge. This will allow you to focus and gain experience to a degree that you might not be able to get at a small company.

Combine depth with mobility (see next), and you have a potential recipe for deep knowledge in many domains, without having to switch companies.

Mobility

At a large company, you often have the ability to move around to different jobs, or to get assigned to projects of personal interest, without having to leave the company. At a small company, on the other hand, if you want to do something different, you might have to leave to find another job.

Formal Advancement

Hand-in-hand with mobility is the idea of career title advancement. Large companies have formal hierarchies, and you can climb the corporate ladder.

Pay & Benefits

Large companies almost always offer better pay and benefits than small companies. Oftentimes the attraction of a small company is rooted in non-financial benefits, and small companies are more likely to pay less and/or offer less in the form of financial benefits. For example, a small company may not provide health insurance, or may require that you pay a large percentage of the premium. A small company may not have disability insurance or life insurance, or a 401k, or an FSA.

Training

Large companies tend to offer formal training opportunities. You may be able to go to conferences, or attend classroom training or online training. Large companies may have tuition assistance programs, to pay for college degrees.

And large companies are more likely to employ experts in your field, who can teach or mentor you.

Here's another interesting perspective. And another (This is YouTube video).

Testers need to be with developers

I once believed that Testing needs to be organizationally separated from development. I once created a testing group, from the ground up. In the group's charter, I specifically called out the need for the testing group to be a separate organizational entity from development. This was important, I believed, because, among other things, it avoided conflict of interest and it better supported the testing ecosystem. I now think the separation of developers from testers is a bad idea. Testers need to be with developers.

There are three primary and fundamental reasons that software projects fail: requirements instability, lack of communication, lack of domain expertise. Ken Schwaber, who is the inventor of Scrum, puts this in terms of the significant “dimensions of complexity” to software development: requirements, people, and technology. “Anything can be complex. When complex things interact, the level of complexity goes through the roof.”

When you physically or politically separate testers from developers, you create communication and collaboration complexity whose resultant problems, in my opinion, utterly and completely dwarf any concern you might have about keeping/putting them together.

I realize that testers and developers are different, in terms of skills required to be good, tools used, etc. So I'm not saying you simply fold testing into development and be done with it. I don't in any way mean to imply that it would necessarily be easy to undo a culture that is used to the separation of developers from testers, or that combining developers with testers doesn't come with its own set of challenges.

Proposal for an Open Work Space

Software development is a collaborative undertaking. Physical work environment is an important factor. In an effort to produce a higher level of collaboration, I believe an open office environment is the best option, providing more value to the business and a higher level of employee satisfaction.

My claims are as follows: Work space design is important. Collaboration is important. Employee satisfaction is important. An appropriately designed open work space will improve collaboration and employee satisfaction. Cubicles and closed office spaces are an inhibitor to collaboration. Improved collaboration leads to improved results.

Definition of an "open work space"

An open work space is a physical work area with a defined outer boundary. The space should be dedicated to a single team. The whole team sits together in a single common room without cubicle borders and works on a closely related set of tasks. The work space design must facilitate ad hoc collaboration by providing things such as visual line of site among the team members and open meeting areas with plenty of whiteboards, etc.

Within the defined boundary, there must be spaces for privacy, such as 1 or 2 offices or meeting rooms; and it should (ideally) provide physical and visual elements that make it a desirable place to be. It should be re-configurable -- people should be able to move desks around.

Here is an example of what an open work space could look like (click the image to view larger):



As much as possible, the team should have control over the look and feel, and have the ability to reorganize their space if they so choose.

Each person in an open office environment *must* have a sense of personal space. It is not appropriate to sling a set of conference tables together and put people two feet from each other and label it an "open office" space. This is important, because so often people are turned off by open office spaces because they aren't set up correctly. We'll get into that more as this article unwinds.

Communication and collaboration problems are an inherent challenge

If you look at studies that discuss project failure -- e.g. the Standish Group's annual Chaos Report -- you can categorize failure into three main buckets: poor requirements management, poor communication and collaboration, and lack of domain expertise. We can often think of the work processes of our individual organizational teams as microcosms of the processes of a larger software project. In other words, anything an organizational team does involves elements of planning, analysis, design, execution, and validation. The same things that cause failure of the larger efforts are problematic for the day-to-day work of individual teams. Poor communication and collaboration are core problems to getting work done on any team.

Improved collaboration leads to improved results

There are essential communication aspects of successful work. Collaboration is a key factor to a highly productive and happy team. The work produced by a collaborative team is better than the sum of any work produced only by its individualistic parts.

Some popular business books have been written about the benefits of collaboration and teamwork:

• The Wisdom of Crowds
• The Wisdom of Teams: Creating the High-Performance Organization
• Group Genius: The Creative Power of Collaboration

Academia also has studied the benefits of collaboration, in the context of collaborative learning. For example, from Collaborative Learning: Group Work and Study Teams:

Students learn best when they are actively involved in the process. Researchers report that, regardless of the subject matter, students working in small groups tend to learn more of what is taught and retain it longer than when the same content is presented in other instructional formats. Students who work in collaborative groups also appear more satisfied with their classes.

Software development is (or should be) a highly collaborative activity. We see much recent evidence of the understanding of the critical importance of collaboration when we look at trends in software development process; e.g. the Agile approaches to software development. From Agile Software Development EcoSystems:

ASDEs focus on people -- both in terms of individual skills and in terms of collaboration, conversations, and communications that enhance flexibility and innovation. As Alistair says, “Software development is a cooperative game.” Most traditional “methodologies” place 80 percent of their emphasis on processes, activities, tools, roles, and documents. Agile approaches place 80 percent of their emphasis on ecosystems -- people, personalities, collaboration, conversations, and relationships.

The momentum of the movement towards Agile processes signifies evidence of the importance of collaboration in software development. From the Manifesto for Agile Software Development:

...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.

The items that Agile values have an enormous amount to do with communication and collaboration. We want to eliminate those things that are barriers to collaboration. And one of those things is cubicles and closed offices.

An open work space is a better choice

A properly established open work space will improve a team's level of collaboration, which will result in more value to the business and improved employee satisfaction. From Open Plan and Enclosed Private Offices: Research Review and Recommendations:

A seminal three-year research project conducted by UCLA revealed that companies who had modified their business processes to encourage collaboration and supported new work processes by moving from private spaces to open, collaborative environments realized performance increases (speed and accuracy of work) averaging 440 percent (Majchrzak and Qianwei, 1996). Research examining human resources, procurement, finance and other functional areas (O’Neill, 2007; Majchrzak et al., 2004) confirms the notion that workspace designed to foster group work has a positive impact on business process time and cost. O’Neill (2007) found a 5.5% reduction in business process time and cost for employees who moved from traditional enclosed office space into a mix of non-assigned and assigned open plan furnishings

And

Vietch, et. al. (2007) studied 779 open-plan office occupants from nine government and private sector office buildings in five large Canadian and US cities. They found that open-plan office occupants who were more satisfied with their environments were also more satisfied with their jobs, suggesting a role for the physical environment in organizational well-being and effectiveness.

To reinforce the idea that work space design is important:

• Good work environment improves satisfaction, productivity
• Workplace design can improve productivity
• Work environment effects on labor productivity: An intervention study in a storage building

Furthermore, cubicles are an inhibitor to collaboration. See Brain death by dull cubicle, or Cubicles: The great mistake.

Physical work space design is part of the overall design of a team, and evidence shows that team design is a critical factor in team performance and employee satisfaction. From How Leaders Foster Self-Managing Team Effectiveness: Design Choices Versus Hands-on Coaching:

Findings show that how leaders design their teams and the quality of their hands-on coaching both influence team self-management, the quality of member relationships, and member satisfaction, but only leaders' design activities affect team task performance.... The difficulties of fostering self-management teams -- particularly in organizations with histories of individualistic, manager-directed work -- have been...attributed to deficits in the...ability of managers to create the conditions that foster self-management....

Also, from What Makes Teams Work: Group Effectiveness Research from the Shop Floor to the Executive Suite: “Team effectiveness [is] a function of task, group, and organization design factors, environmental factors, internal processes, external processes, and group psychosocial traits.”

Keith Sawyer is an author and university professor and is considered one of the country’s leading scientific experts on creativity. He is the author of Group Genius: The Creative Power of Collaboration, which was the 2007 winner of Best Business Book on Innovation. He is a professor of education and psychology at Washington University in St. Louis. He says:

What kinds of offices foster creativity and collaboration? They are offices that support flexible work arrangements and frequent spontaneous reconfigurations, of people, furniture, walls, and cubicles. In innovative organizations, you find a blend of solo work, work in pairs, and collaborative teams. But most of today’s offices are designed to support only one kind of work: solitary work, alone in an office (or a cubicle). In innovative organizations, people are always moving around, bumping unexpectedly into others, and stopping for a few minutes to chat.

And...

...for a group’s genius to be fully realized, several things have to happen. First, the members of the group have to share a common body of knowledge -- and on top of that, they each have to know some uniquely different information. Second, they have to trust in each other. But trust doesn’t mean everyone always agrees; it allows them to challenge other’s ideas, and to propose crazy ideas of their own. Third, they need to interact with each other, in a special kind of open, improvisational conversation [my emphasis] -- where something unexpected can emerge. The best genius groups are like improvisational jazz ensembles. The outcome is unpredictable, and it depends on a complex sequence of small actions and interactions.

A framework for an open work space

The open work space and the team's work processes need to exist in such a way as to minimize undesirable effects, such as unwanted or irrelevant interruption. There needs to be a balance between the need for collaboration and the need for concentration. Taking a page from Agile development processes such as Scrum, to minimize unwanted interruption we need to set up a framework for the open work space that includes the following:

• The team's physical work space should have a physical boundary, such as walls or an entire room, to shield the team from external distraction.
• The team needs to be working on a shared set of tasks -- i.e. it should not be treated as a resource pool for a larger organization.
• The team's work should be time-boxed (2-4 weeks), allowing the team to focus for a period of time on a set of tasks without change of course from external forces.
• The team should hold daily stand-up meetings to discuss work status, which establishes daily focus and reduces unwanted ad hoc coordination.
• The team's work space should include one or two shared private offices, which can be used by team members when needed, for individualized focused work.

Within this framework, any negative effect of distraction or interruption is mitigated. By setting up the open work space within the context of an appropriate framework, an environment is established which facilitates a team's journey to become highly collaborative and more effective. The article Scrum and Group Dynamics helps to explain some of the theory and principles for how a team becomes successful within such a framework.

An open work space may arguably be more monetarily costly -- in its entirety -- than a typical cubicle environment, depending on how much space you give to each person and how much collaboration space you give to the team. In an open work space, an individual's personal work space is actually less costly than it would be in a cubicle space, because open work spaces do not require walls. A person just requires a desk, chair, computer, and some storage (desk shelf, filing cabinet).

People will also have a need for some personal privacy. Any team member can use the shared private offices when they need privacy.

It is inevitable that some people will not like an open office environment or are not going to be willing to try it. If possible, we do not want to push people into something they do not want to try; and we want to give those people the ability to opt out. People who have not worked in an effective open work space are typically going to be initially hesitant. We need to be cognizant of these facts and work to convince people to try it.

Employee satisfaction is impacted by how an open work space is designed. The work space needs to be set up in such a way that people do not perceive the space as crowded. See Research and Design Recommendations on Crowding in Open-Plan Offices.

Metrics

I claimed at the beginning of this article that an open work space would result in the team providing more "value" to the business. I purposely didn’t frame the goal in terms of productivity -- e.g. "the team will become more productive". Attempting to measure productivity is problematic, especially in the context of software development -- see how do you measure the productivity of a tester. I believe it is better to frame the goal in the more abstract and qualitative concept of "value".

It is important to note that saying "increase the value" is the same as saying "improve the quality". We could restate the claim of benefit of an open work space as "improving the quality of the team's work", and it would be saying the same thing as "increasing the value of the team". Quality and value become synonymous according to Jerry Weinberg’s definition: “Quality is value to some person.”

Side note: The phrase “quality of the team's work” refers to the quality of the product that is produced or quality of the service provided by the team – i.e. in the case of testing, it is the quality of testing, not the quality of the product being tested. This sometimes can be an important distinction.

We could think of increasing value or quality in many ways:

• Increase the volume of work with the same number of people
• Get the same amount done with less people
• Get work done quicker
• Become more effective (better tests, more coverage, reduced test errors)
• Increase the variety of work that the team can handle
• Find more bugs
• Let less bugs escape to the customer
• Get the team more knowledgeable, and thus more valuable
• Etc

But we need to avoid the pitfalls of trying to measure these things. Knowing that quality is value to some person, and that "value to some person" is qualitative, and that we want to keep things simple, it might be best to use survey mechanisms to measure a team's value. Identify those groups of people to whom the quality of the team's work is important -- e.g. business/product owners, developers, management, and the team itself -- and ask them to rate the quality of the team's work or their perspective of the value that the team provides. Maybe on a 1-10 scale. And ask them to provide a comment.

E.g.:

1. How would you rate the value of the team? 1 2 3 4 5 6 7 8 9 10
2. Please comment on your rating.

I also claimed that an open work space will improve employee satisfaction. We can also measure this with survey questions. E.g.:

1. How would you rate your level of satisfaction with your work space? 1 2 3 4 5 6 7 8 9 10
2. Please comment on your rating.

Summary

An open work space is just one part of what should be a bigger effort to maximize collaboration and create highly effective teams. For teams that are stuck in the traditional command-and-control management environment, moving to an open work environment can be a great catalyst to positive change, because it is so visible and different.

The following comment, which comes from Creative Class, is typical:

[Our] space is almost completely open plan. We designed it with a library/ lounge filled with books and sofas and tables; a big room for seminars that seats 15-60; a conference room that seats 12-16; a bullpen for group work; and a cafe for socializing. We included 3 private offices; and were told that was too few. Let me tell you. Our big room has turned into an incredible project space. The offices are doubled up in. Our library/lounge has become a seminar room, we had a class of 20 or so there today. If we had to do it again, we’d probably give up all 3 offices. I spend precious little time in mine. We’d take as much reconfigureable group space as we could get out hands on. Yet we are by far the exception in an academic environment, which is built around private offices for professors, classrooms, and cube farms for research assistants. I may well be the first professor in my unit to give up a private office.

An open work space is the best choice.

Why to Work for a Small Company

I've worked for very small companies (less than 50, privately held) and for very large companies (50k+ Fortune 500), for significant periods of time and in a variety of software development roles.

Below I've laid out several reasons in favor of working in software development for a small company. I'm not saying that these things are guaranteed, but I am saying they are out there and you can find them; and you are more likely to find them at a small company. Caveat emptor.

I also have a post on Why To Work for a Large Company.

Generally speaking, based on my experience, work for a small company if you value...

Risk Taking

If you are going to work for a small company, you should be somewhere on the spectrum between risk tolerant and risk-loving. Here are some risks: the company could fail for reasons beyond your control, the owners and/or co-workers could be difficult to work with, decisions that you make could negatively affect the company, everyone knows when you fail.

But for every risk, there is a potential reward. That's part of the thrill and payoff of working at a small company -- the entrepreneurial spirit -- taking risk and reaping the reward. Yes, everyone knows when you fail; but everyone also knows when you succeed. And your personal successes can have a highly visible and significant positive impact on the success of the company, the success of the people your company serves, and your own sense of self-fulfillment.

Connectedness

You should work for a small company if you enjoy the feeling you get when you can easily relate what you work on to the success of the company or the impact it has on the success of the company's clients or end users. I.e. You have a strong desire to feel like you are making a difference and helping others to succeed. When you are at a large company, that connectedness is often missing.

Like-Minded People

People who work for small companies are more likely to have values that align with yours and that are on this list. I.e. Risk-takers, entrepreneurs, optimists, do-ers, etc.

Less Incompetence

At a small company, you cannot hide. Everyone knows when you fail and everyone knows when you succeed; and the company cannot afford incompetence. Because of this, incompetence gets weeded out.

Familial Culture

Small organizations tend to take on the personality of their leaders, so if you find a small company whose leaders share your personal values (E.g. honesty, integrity, sense of humor, etc), the vast majority of the employee population is likely to also share those values; and this makes for a very nice fit and a familial atmosphere. It's hard to find this type of atmosphere at a large company.

Variety

At a small company, it is likely that you will become a generalizing specialist. In other words, according to Scott Ambler: "Multi-disciplinary developers, cross-functional developers, deep generalists, polymaths, versatilists." This will be true with respect to the technology and tools, the people you interact with, the domains you work in, and the roles you play.

At a large company, as a software developer, you are more likely to have a singular purpose (e.g. DBA, Performance Tester, Project Manager, etc.), where you can acquire a depth of knowledge within your narrow domain. If depth is what you are after, a small company might not be the best option.

Personal Marketability

My experience has been that breadth makes you more marketable -- it gives you more career options. Exposure to a variety of things also helps you to discover areas of personal career interest that you might otherwise have never discovered. Small companies help people to attain a more well-rounded skill-set.

Of course, breadth has a dark side: "jack of all trades, master of none". If you have to make a transition to a specialty, you will be behind others who already have that depth; but it has been my experience that, for career advancement and security, breadth is better than depth. There are exceptions, of course.

No Nonsense

Small companies tend to be very lean. Process and bureaucracy are overhead, and small companies don't want it and/or can't afford it.

Small companies do not suffer from the complexities of communication like large organizations do; and thus they do not tend to put in place restrictive, bureaucratic, and frustrating processes. Small companies tend to be agile by default.

For more on this, read up on Diseconomy of Scale.

Fast Pace

No nonsense translates into a fast pace. You don't rest on your laurels. You may work a lot of overtime. The cadence is just plain fast most of the time. You probably won't be bored. If you like to be busy, you will like working at a small company.

Flexibility

At a small company, there tends to be more flexibility in your terms of employment. Many aspects of your terms of employment may be negotiable, such as vacation, work schedule, etc.

Small companies tend to be more laid back about certain things, such as dress code and your personal work space. Jeans and t-shirt may be every-day attire. Perhaps shorts and sandals in the summer. Arrange your desk the way you want it. Put software on your computer without having to get permission. Listen to music. Take a mental break and play a game. Bring your dog to work.

Responsibility

Empowerment at a small company can vary greatly according to the policies and whims of the owner. It has been my experience that there is more empowerment at a small company. If you think about it, based on what I've previously said, this makes sense. There is less incompetence, which leads to more trust, which leads to empowerment. There is less overhead, which translates into less micro-managing, which leads to empowerment.

At a small company, you will have a responsibility to influence what the company does as a whole. You will have direct access to the owners and other decision makers. You may have direct access to the customers as well, and an ability to make decisions on your own based on what customers are asking of you.