In the industry, there is a distinction made between an 'in-house development' environment where the software developers are writing code which will be used by the company itself and a proper 'software development' environment where software is built to be sold/distributed to the public.

Among others, one obvious difference between the two is that a software-development-oriented company will typically adhere to some sort of software development life cycle such as spec-writing, testing, building etc. whereas the in-house-oriented shop will usually do things in a more casual way since they themselves are the end-users and can always fix something that wasn't done right.

As a student (like most other students), I kind of expected myself to wind up working in a software development environment, but I ended up getting my first position at a firm which operates in more of an in-house fashion.

At times, I wonder whether I am missing out on the full-fledged software development experience. Is there a basis for this feeling? Should I seek to join a proper software development environment?

  • 9
    I think you are over generalizing. The methodologies used have nothing to do with in-house products versus commercially-sold projects. I've worked on a shipped product that was developed very ad-hoc, ignoring many of what would be considered best practices. I've also worked on in-house projects that had detailed specs, test suites, and a plethora of quality control practices.
    – Thomas Owens
    Dec 19, 2011 at 20:01
  • Both questions you've posed can only be answered by yourself.
    – leo
    Dec 19, 2011 at 20:04
  • 6
    IMHO, your problem has nothing to do with missing out on In-House vs. software company. You sound like you are suffering from being in an unstructured development environment and not having a strong mentor who helps you follow best practices.
    – maple_shaft
    Dec 19, 2011 at 20:26
  • 1
    Whether the software is developed for sale or for internal use, it's all called "software development." Commercial might be a better term than what you call 'software development.'
    – Caleb
    Dec 19, 2011 at 21:03
  • 1
    You are conflating two dimensions of software development -- ad-hoc vs structured development process, and in-house vs product development. The degree of each can vary independently. Dec 20, 2011 at 16:04

4 Answers 4


In my experience, the distinction you are making between "in house" and "distributable product" is false.

There are companies that take their software development process seriously and those that don't. Whether they are "in house" or "bespoke" or "shrink wrap" tends to not come into it as much (though if they are "shrink wrap" providers, if they don't have process they will probably not be in business for long).

You should look for a place that has the standards of development you are looking for - when interviewing you need to ask these questions to ensure the place is to your liking in this respect (as well as other).

  • I was writing something similar to this when you posted. +1 just for the last sentence, although it's all valid points.
    – Thomas Owens
    Dec 19, 2011 at 20:08
  • @ThomasOwens - Yeah, saw your comment to the question after posting my answer and was expecting an answer as well from you ;)
    – Oded
    Dec 19, 2011 at 20:09

You may read this article


of Joel Spolsky, which is exactly dealing with your question.

I am in a position where I had to work on both the last years - a medium-sized software product beeing sold, and some in-house software. From that experience, I can tell you there are differences between those two platforms, but the situation is not that bad as Joel described it.

For example, most of our in-house software has to run only in a very restricted environment. Lots of tools just working with a certain spreadsheet or database version, with a specific network environment, with a restricted number of users, no installation routine needed etc. That makes a lot of things easier and quicker to develop as compared to new features introduced into our shipping product. On the other hand, that does not mean my code for the "in-house" programs has lower quality or is written in a more "casual way".


A long time ago, I read a book on Agile Project Management (I wish I could remember the title), where the author distinguished systems based on their levels of tolerance for system defects. Tolerance for defects could range from very high -- for example, a utility used by other developers (where bugs are merely an inconvenience), to very low -- for example, a system which is running life support for astronauts (where a bug could be life-threatening).

The author's point was that the development methodology (and formality) needed to be scoped to the failure tolerance (or criticality) of the system. I think this distinction is the most important one, as opposed to distinguishing between in-house development versus software for general distribution.

Imagine a hospital which has in-house developers building medical record systems which could impact quality of medical care. In this case, the in-house shop would likely be more rigorous than a web site consultancy, who is building web products to be used by the general public.


I've worked for software houses, marketing agencies, mobile phone telcos and banks, one thing I'll say, its the company's culture and industry which dictates the level of processes applied. The most rigorous, slow, restrictive and tested environment I ever experienced was in-house development for a bank. The most casual was a marketing agency.

I'd recommend learning from this experience and use it to decided your future direction for your next job. The software development industry isn't a science, its art/science hence the variation and differences from company-to-company. It's more important you learn to do things right regarding your code. Although making a mental note of the failures or lack of processes is useful, so when your manager you can implement a better processes.

Not the answer you're looking for? Browse other questions tagged or ask your own question.