Recently, I was approached by a local ad agency with a job opportunity. They are bringing all web/interactive development in-house and adding to their development team.

I'm growing sick of my cushy, yet boring corporate job, and am intrigued by the position.

Having only worked for software shops where the primary business was making software, I worry that they may not put emphasis on quality software practices, since development is not the focus of their business.

Could anyone with experience at both compare/contrast working at a software company with working at a company that just happens to have an in-house software development team or department?

  • food, clothing, shelter...? Feb 8, 2011 at 2:00
  • I work at a company that produces "software" but I don't consider them a software company, more of a sales outfit that aggressively pushes crapware with a little effort (from the owner / manager, I mean) put into planning software development... I am quitting very soon though, anyways I guess the point of my rambling is that even "software" companies can be pretty bad to work for, at leas if they're small Feb 8, 2011 at 19:24
  • 4
    I doubt that every single ad agency is the same; why not interview them and find out?
    – Aaronaught
    Jul 28, 2011 at 15:56
  • 3
    I'd guess that working at a non-software company could be extremely rewarding if you are actually interested in the industry they are working in. Jul 28, 2011 at 16:01
  • 1
    Any company that has a business interest in creating software is a software company. Car companies need software in the on-board computers in the cars that they sell; and so they are software companies. Aug 3, 2011 at 17:01

14 Answers 14


It will depend on the company. But usually, if it isn't their main focus, the software will be of lesser quality. The process, if they have any, will be less stringent. The testing non-existant. And the work overall less technically challenging.

They'll want it to work, and work now, and that'll be good enough.

But some places are hip about software development, even if they're mom & pop shops doing something else entirely. It depends on the business leadership being open to good ideas, the tech leadership knowing enough to do it right, and having people that can explain a good idea. Which might be you.

Interview the company. Ask them if the know of/adhere to the Joel test. Most of them are good points. See if they understand technical debt and the mythical man-month. Who is your project manager, what process does he use, and how geeky is he?

  • 3
    Good answer, I think the "work now, and that's good enough" is my biggest concern. Those are good tips for interview questions also. Jul 28, 2011 at 17:44
  • 5
    I almost -1'd for "less challenging" - but the rest of the post I agree with. Worked both in SW shops and in operational corporations for 20+ yrs, & have to say that the operational shops are just as challenging. 1) you as the developer face your customer directly every single day. 2) you don't worry about scope creep - it's scope explosion. 3) the business throws anything and everything at you, in quick succession - you don't have the luxury in spending a day or a week on a module in peace, you take what time you get. NB: not saying SW shops are all roses - they aren't. Jul 28, 2011 at 21:25
  • 3
    bear in mind that wanting it to work and work now is sometimes the right decision, ultimately you have to understand the business
    – jk.
    Jul 28, 2011 at 21:46
  • 1
    Also on difficulty level: When comparing enterprise software to typical commercial OTS (excluding stuff like games, device drivers, embedded, etc.), you'll usually end up dealing with more stringent reliability and performance requirements, which often trump concerns about the user experience. It really does take talent to keep these all in balance. The software quality is often lower simply because these companies have a hard time attracting the smartest developers (often justifiably so).
    – Aaronaught
    Jul 28, 2011 at 23:40
  • 2
    This is my experience. It depends almost entirely on the particular company but on average a non-software company is more likely to have a bad environment and slothful/lazy developers that only care about getting things done quick instead of doing things right. Aug 3, 2011 at 18:20

There's a HUGE difference. In the former, you're part of a profit center. In the latter, you're part of a cost center. Guess which one gets better treatment?

I work for a software company now and am SO much happier than I was at my last job, where it was all layoffs & outsourcing all the time, and developers were just seen as easily replaceable widgets (instead of the heart of the company).

  • 5
    +1 - Every industry has one or two positions that are seen as the "money-makers". They get special treatment and special recognition. You want to be that guy, not the guy who they keep around only so the other guy's job is easier.
    – Brook
    Jul 28, 2011 at 23:47
  • Layoffs are usually tied to how close you are to the line of revenue. Even as developers at software companies you are quite far from the line of revenue. You will soon find the rock stars are account managers,sales folks, and technical acct managers. Layoffs a lot of times in those companies happens in project mgmt, prod mgmt, and software development teams. Ofcourse YMMV!
    – CoolBeans
    Jul 29, 2011 at 15:07
  • I think it depends on how dependent the company's profits are on the software being built. In financials, a few scripts might land a 10 million dollar contract because some functionality was required and available no where else. Some industries do not sell software, but what they do sell is not much more than the output of some custom software. This puts the developers pretty darn close to the profit center. Not to mention, sales people are a dime a dozen with this economy (in my area at least), while capable software developers are harder to come by. When sales==dataEntry, I feel safer in SW. Aug 3, 2011 at 18:44

Programmers are still programmers. Just because the primary product of the company isn't software doesn't mean that a programmer doesn't need the same amenities.


The difference largely depends on the company itself; I've worked at good non-software companies and terrible software companies. On average, though, here's what I've found:

Non-Software Company

Emphasis is on getting things done quick, with little or no thought given to quality or long-term maintainability. Developers are usually technically ignorant beyond what they've done in the past or during their time with the company, and often trying to introduce new concepts (ORMs, SOLID principles, TDD, etc.) will be met with confusion or immediate dismissal. People tend to focus more on "towing the company line".

Software Company

Emphasis on getting things done without sacrificing quality. Co-workers are more likely to keep up to date with technology (whether or not they can utilize it at work) and often look how they can integrate new ideas or frameworks into the daily routine to make the software better. If they aren't already familiar with and are using concepts like TDD, ORMs, SOLID, etc. they have probably heard of it and are more willing to evaluate them.

Again this is in the end company dependent. I worked at a non-software company with an extremely Agile team that embraced TDD and ORMs and taught me a lot about proper software engineering, and I worked at a small software company that wrote VBScript spaghetti code of the worst kind and have 50+ developers that each had to work on different pages to avoid things breaking, and tons of red tape for even a minor change. However, the less the company outwardly relies on software, the more likely the environment will be very poor for software development.


I have worked in the IT department of large companies developing software for in-house use; I have worked in companies developing software for the market; and I have worked in agencies doing web development for clients.

And I would not say there was any difference whatsoever between those different companies in terms of the importance of productivity boosting things.

Keeping programmers productive is vital regardless of what sort of development those programmers are doing. And I would say that keeping programmers happy and keeping them working for you is even more important when they are maintenance programmers in the IT department of a non-software company.


One difference for certain will be less emphasis on the overhead and redtape that you have to go through at a corporate software shop. You will find that you will be able to have much more granular control over all aspects of your projects.

One pro is that this can be refreshing...

It turned out horribly for me personally though but that just may be because I chose poorly. One HUGE con is that you are no longer tied to the bread-and-butter of the business and instead you are an administrative overhead. Budget controllers treated me like I was personally taking money from their own wallets and proceeded to "beat me like a rented mule" so to speak. For me it was an infuriating and exhausting ordeal so you should carefully look for signs of this kind of attitude when you interview.

  • 3
    "Why should we buy a new compiler? Has the old one gotten stale?" Jul 28, 2011 at 16:58
  • Thanks for the tale of woe :) To avoid this, I need to determine what? If management gives the current developers the trust and resources needed to do their work? Jul 28, 2011 at 17:57
  • 2
    @stormwald, Good question, when you go on the interview, ask them WHY they feel that having an in-house development team is the right move rather than hiring contractors our outsourcing which is the standard move. If their answer has to do with cost then I would avoid it.
    – maple_shaft
    Jul 28, 2011 at 19:19
  • It's also worth asking how the company funds its IT. Is there a specific budget for it or does it come out of operational expenses.
    – CdMnky
    Jul 29, 2011 at 15:48

I've worked as the only software developer on a floor of non-software people, and I think independence is even more important in that case. When you don't have dozens of people using the same tools, you have to make a lot more decisions—what language you will use, what compiler, what servers, etc. Lone developers need more freedom to install, evaluate, and administer software that's taken for granted in a group setting.


There's already some great answers here, but I'd just like to reference a link to the transcript of the 2nd part of a talk that Joel Spolsky gave at Yale University:

Joel Spolsky - Talk At Yale Part 2 of 3

There he talks about the difference between "in-house" programmers and programmers that work in software/technology companies.

His three main points are:

  • When you're an in-house programmer, you never get to do things the right way. You always have to do things the expedient way.

  • As an in-house programmer, once some software is “good enough,” you stop working on it. When you develop software "products," you get to make them beautiful.

  • When you’re a programmer at a software company, the work you’re doing is directly related to the way the company makes money. That means, for one thing, that management cares about you.

Personally, I've worked at both software companies and non-software companies throughout my career, and although there are always exceptions to every rule, I do agree with Joel's points as the vast majority of companies seem to be in accordance with them.

  • +1 for the excellent link! Never underestimate the value of getting to make beautiful things. Aug 17, 2011 at 14:58

One major difference is that working at a software shop you are probably helping to generate jobs within the company. Working in the programming dept. at a different type of company is, in general, going to mean that you are writing software to replace people. It's a depressing reality to deal with. That being said, an ad agency may very well be a different beast entirely. More like a web dev shop within another company, would be my guess.


Well per my observations there are at least two cases when sticking with software company borders to matters of professional survival.

First case is if one is totally into coding - give me 80... 90... 100% time to code or I die. At software shops, this is almost a granted, as if everybody knows how to get there because, well, because everybody is doing just that. But outside, there is a really high risk to fail getting there. One may get as low as 50, 40, 30% (my personal coding load once dropped to 20% - no kidding, I measured in JIRA!) It's not because "they" don't want you to code - no they want but, but... they may just don't know how.

Second "deadly risk" is if someone has serious problems in communication. This may be troublesome even in software shops, right, but at least there are good chances to survive and live a nice productive life without disturbing interactions. :) At non-software companies though, such chances are much lower - quite an opposite, it's almost inevitable that one will eventually have to spend much effort to educate some outsider in IT basics just because otherwise it will be impossible to do the job.

Well except for two cases mentioned above I know no other strong reason to strictly lock self to software companies. Now, which side to prefer? as far as I can tell, this is more a matter of taste, of what kind of fun clicks more on you.

Both sides offer their own, distinct forms of getting fun. It's not easy to describe.

I'd say software companies are more fun to those aiming at "high marks" while outside ones give a thrill to those striving for "big difference". I think of it about like this (note numbers below are invented only to simplify making a point)...

  • At software firm, one has a chance to deliver 100 features a year - a highest mark nobody yet achieved. It's gonna be hard, it's gonna be tough, it's gonna be top - making a cool 50% improvement over average 70 features a year. Great challenge, really.
  • At the same time, in outside firm one has a chance to deliver 50 features a year - a highest boost nobody ever achieved. It's gonna be hard, it's gonna be tough, it's gonna be big - making a whopping 500% boost over average 10 features a year. Great challenge, trust me.

Note btw that chances to get 500% boost at software company are negligibly small in comparison - and respectively, chances to achieve 100 features are negligibly small outside.

Top marks at one side expand our understanding of professional limits, improving our knowledge of how to do things better. Big difference at other side makes a deep impact on the company culture, improving outsiders knowledge on how to to it right.

Now, if you have a clear preference for one or another, you know what side to take. Or, if you're indecisive, just feel free to swing between them as you wish. :)

  • I've never measured "fun" or "challenging" in terms of how many features I've banged out. I did do some investigation one time that led to a 100% performance improvement, which was pretty cool.
    – Kevin
    Aug 3, 2011 at 17:54

Kudos to the cost vs profit center response.

I've been in both and would much much prefer a software company. Since your correlation to profits is more obvious, your more likely to have some proper performance based compensation and an overall corp culture that embraces a software developers personality. Often that translates into less office politics, Dockers not required, obvious career paths, and less BS. But if your more into a steady 9-5, perhaps less challenging, not cutting edge type gig than sometimes corp IT is a better deal - not being cynical here, I understand some people like a more typical work/life balance at the expense of other things. In my experience the overall quality of a developer is much, much better at a software company; opposed to the mediocrity that often permeates corp IT. I know that there are exceptions, but this is based on my experience of the avg software corp vs avg corp IT dept.


I recently worked at a large American non-software company where a colleague heard the CEO say "I don't give a f*** about software I run an **". In my experience this is par for the course. There will almost inevitably be issues that seem obvious to the software team but the non dev management will refuse to even think about.


I.T is part of the Support group in non Software Companies..Software Programmers developed applications that will help the company for much better productivity,faster transactions,technical support etch... Some Non software companies(Manufacturing/Industrial etch) offers trainings and other things to their programmers but many are not, so they used to outsource Programmers in Other companies.


Could anyone with experience at both compare/contrast working at a software company with working at a company that just happens to have an in-house software development team or department?

I'd rather contrast working within an IS department to working in the product development arm of a company that sells software. Just to clarify each side and give some of each, with some formatting corrections:

IS department

The company may make hardware, software, cars, or whatever but the key here is that there is an internal department that is responsible for the systems that the company uses day-in and day-out. In here there can be frameworks like ITIL that can try to bring some maturity to the processes that the department runs as part of this department is the infrastructure guys that keep the lights on and the other part is the development and analysis guys that put in improvements, enhancements and new systems. Here projects can vary in length though in some cases in can take years to get a system fully implemented due to phases in the roll out if some big system is being replaced like a CMS, CRM or ERP.

At times I have had the feeling of being a cog in a machine and at others it is rather neat to be part of the backbone of the company for the lows and highs of such a position. I don't get to brag to people outside the company too much because most of my work is on internal systems that isn't intended to be publicly accessible or viewed. Here there can be support tickets where one may have to deal with vendors of software as someone has an issue that isn't necessarily something where it is easy to know what caused the error and so the IS department has to follow-up with someone else to help resolve the issue. In other cases it may be that some customization has to be altered due to changing requirements or business rules.

Software company

Here this is working on what the company sells directly and thus there are some big rule differences. First, the customer here can't be boxed as much as the IS department case. In the IS department there may be just a few users of a system so that governance can take care of many odd cases where if someone intentionally chooses to misuse a tool, that can't always be prevented. In the software company there isn't that safety net. If someone downloads your software and they manage to find a way to do something rather destructive with it, the company may get a big black eye for it. In this case there can be some showing off of what I did as there may be some cool feature to show a friend or relative if they want to know a bit more about what I do.

Something to note here is that there can be companies that are brought in as system integrators to put in big customizable enterprise software that work with people in IS departments on the million dollar implementation of stuff as well as those that work directly for the company making the big software itself. There can also be application service providers that I'd put under here as they are selling a service that is built mostly of software usually. For example, Google may have an IS department as well as a number of software developers even though one wouldn't go to a store to buy a DVD of Google's software, at least I don't think I've seen that though I do know of many Google products on-line that can be used rather easily. This can allow for some specialization as it isn't likely to be as diverse as the IS department where a general application developer could support dozens of different applications.

  • 2
    I'd consider splitting your answer up in paragraphs, because its pretty hard to read it like this.
    – Ivo Flipse
    Jul 28, 2011 at 17:30

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