Software developers in the corporate environment

Question

I’m interested in some feedback from the folks out there who have experience with developing software in the corporate environment. I’m talking about organisations whose core business is not technology related and the role of IT and subsequently software developers are considered enabling functions. There are obviously some fundamental differences working in this sort of environment as opposed to with an ISV where the express business purpose of the organisation is to build software.

What sort of challenges have you experienced in this sort of environment? What particular strategies have you employed to overcome these? What are the pitfalls and conversely the advantages of this style of working?

Consider issues such as career progression, PC hardware and software, autonomy, corporate policies, etc (probably many more considerations I haven't listed). I appreciate this is a pretty broad question but would be very interested in the experiences of others.

Answer 1

The biggest issue I have experenced with corporate IT is the notion that it is not important enough to do in-house. It is viewed simply as service to be outsourced to the lowest bidder.

EDIT: I would like to add that the solution to this is to deliver real value to the corporation beyond what can be offered by an outsourcing firm. In my opinion this requires Business Process Reengineering. In other words the key is to understand how the business functions in a far greater level of detail than any outsider could AND have the ability to change the business processes with the assistance of computer systems.

In many, many companies middle managers are highly resistant to any changes which will dramatically restructure their fieftoms, that is why BPR rarely occurs in an effective manner.

Answer 2

Two words: scope creep

People from a non technical backgroud/people that are not used to project management think it's fast and easy to keep adding features to a project that's underway, then they don't understand why deadlines are missed and costs exceed initial estimates.

Answer 3

I think the biggest challenge is in the education of the rest of the business as to the importance of the IT function and justification of the overheads that it generates. Alignment of technical aspects with business aspects is a tricky subject also - educating people in marketing, sales etc... as to the importance of internal IT projects as opposed to revenue generating projects is a big challenge.

It's difficult for the rest of the business to grasp the concepts of consolidation, i.e. refactoring/architectural rework, server upgrades etc... It's also a little more frustrating in terms of an environment to work in - as a developer at least. Lots of justification (and education) is required for project x coming in a week later because of this kind of work.

Outsourcing is often the first thing considered for projects in these sorts of environments - it's a difficult one for us to grasp as internal IT people because we know the quality of the software coming back to us is going to be substandard, because it's rushed and often completed to a fixed time/cost agreement. With processes such as tendering I guess that's the consequence. I'm sure it works well in some cases - I'm still waiting to see those though.

Oh and politics, politics, politics with other departments...seems to get worse the bigger the organisation. Sorry, a little pessimistic on this one, but I do stress they are challenges that can be overcome with time.

Answer 4

It's really hard to be in a software cost center. Nothing people here don't know, but software and esp. good software is very, very expensive to make. When things go bad for a company or there are down economic times and cost cutting is on the menu, the software cost center usually takes deep cuts. I have kept my career oriented to where I am always in a profit center for my company and I have been much the better for it.

Answer 5

One of the biggest issues that I have seen in a company where you are not directly adding to the core business is that you are viewed as a cost centre. IT is viewed as a necessary evil in a company of this sort. They need to have functioning computers and internal software but there is no incentive for them to invest any money into it. It does not directly effect the bottom line. This is often why large companies like this outsource IT work offshore. Anything to reduce the cost they see as being better for the organization.

The best way to try to overcome this is to do a great job. If you do a great job, provide great services or software to your internal customers, people will notice. If you follow the 'norm' and just go with the flow that only reinforces the views of management about IT in general. If you do a great job, you will be noticed and consequently may give the department more respect.

Answer 6

The conflict between the bean counters, who want to treat the results of your development as assets to be managed, and the operations folks who view your product as simply services to be procured creates an environment where truly stupid decisions are taken in the name of compromise (or synergy if you prefer management babble).

Some industries, like banking and insurance, have a long history of computer related product development and usually have a very pragmatic, but effective approach to development. Others, including local governments and startups, lack understanding of TANSTAAFL principles and can consequently create very problematic, soul-sucking work environments.

Answer 7

In my experience in non-software companies, it's can be hard to get promoted while remaining in a non-managerial role. There's often a well-defined "manager" career path, but no corresponding "developer" career path. This tends to devalue "pure" developers relative to technology managers in the eyes of senior management, and leads to the erroneous view that all developers are equivalent. I think that this makes it harder to retain good developers; it's demoralising to work in an environment where your skills are not appreciated.

Answer 8

One of the most frustrating things as a developer that I have experienced in every non-software centric company is the acceptance of bad software.

"If it isn't broke, don't fix it." Now I agree with this notion, however, defining what's broke is very different between a software developer and a manufacturing business manager.

It seems like many corporate teams spend their careers nursing along old, bloated, smelly systems because "it isn't broken". This can drive you mad, as well as stagnate your own career.

---

Also, as far as PC hardware and software, I have personally had issues with procuring these at a non-software company. Odds are, though, that a company with software at its core business will recognize the value of a refactoring tool or dual monitors.

---

All that being said, you really have to take it on a company by company basis. I've worked for one corporation that really valued my skills and provided me with tools and training I never would have thought possible.

To find a good company, you really need to be prepared when interviewing to ask the tough questions. If a potential employer isn't able to answer your questions, you probably want to look elsewhere.

Answer 9

Gathering requirements is hard. You'll run into the attitude "This is important for you to do, but not so important that it's worth my time to tell you exactly what I want." Or "This is too complicated for me to write down. Let me just tell you about it."

It helps to develop in short iterations. People don't know what they want until they see something. Use prototypes, wireframes, etc.

Non-functional requirements are overlooked and undervalued. One way to make these more visible is set up some straw men for the client to knock down. That way they feel like it's something they're asking for rather than something you just want to do.

• Is it OK if this application has a few security holes?
• Can we take the application down for 24 hours now and then?
• Is 2-minute response time after clicking "submit" acceptable?

You want to be subtle. Don't ask something they'll think is ridiculous. You want to ask something just bad enough that they'll say no.

Answer 10

I'd say the toughest issue in moving to a corporate environment is modifying how you think of cost, benefit, and risks.

A simple cost of say upgrading to a different browser could be hundreds of thousands of dollars just by the sheer scale and magnitude of change across the organization.

A developer must also think in terms of deploying to a very locked down environment. We can't just tell a few business people to "install this add-on" or "just use Firefox" if the corporate standard is a centrally controlled configuration.

The biggest issue, though, is trying to meet the needs of a target audience that really isn't looking forward to a new, improved UI or something that supports the newest buzzword of the day. For the most part, people want the impossible of vast improvements with no changes.

Answer 11

Here are some challenges I've seen in a large corporate environment.

Balancing the needs of individual business customers with those of the organization at large. In a large corporate environment there is a fiction called "the business". Other development teams will say "we can't do that because the business doesn't want it", or people on the business side will say "we're the business, so we want x/y/z." People will invoke the name of senior management if they need to. The truth is that "the business" is really a collection of separate groups with their own respective and often-competing goals and agendas. When you serve a given business customer you're often in the difficult position of balancing the needs of that customer with the needs of other business customers. The people with decision-making authority are often too busy or too far removed from the details to exercise that authority in a thoughtful way.

Learning how to work with lots of other teams. In a corporate environment there are so many different kinds of teams--both on the technical side and on the business side--and each has its own language, culture, processes, organizational issues, concerns and so forth. It can be really tough for somebody coming in as a pure developer to understand these other teams--even simply understanding the meaning of the words coming out of their mouths. The QA team will talk about test plans, system testing, regression testing, corner cases, etc. and you may or may not understand it. The operations team (actually there are many different operations teams) will talk about load balancers, VIPs, the NOC, end user monitoring vs. system monitoring, ITIL, incident vs. problem management, HP OpenView Service Navigator, content distribution networks, etc. Marketing may talk about SEO, media buys, ad creatives, A/B testing, Google Analytics, focus groups, etc. Those teams feel the same way about development, by the way. (They have no idea what we're talking about when we mention source control, configuration files, IDEs, etc.)

Wide range of technology to understand. In a smaller shop there might be a reasonably constrained set of technologies that you are expected to understand. In an enterprise it is large, and in general you will have to be able to speak intelligently about things that you have never personally used.

Getting lost in the crowd. It's harder for developers to stand out in a large environment. In a smaller shop, you have more direct contact with management and so it's easier for management to get a good feel for what you bring to the table even if you aren't from a purely statistical standpoint an outstanding developer. Your manager is more likely to know, for example, that you come to work on the weekends. When there are more people it's harder just because management attention is a scarce resource. That's not to say you can't stand out--you absolutely can--but you have to be in the top 5-10% or so of the engineers there, and you often have to be willing to "market" yourself in a way that many engineers find uncomfortable or even distasteful.

One thing I will say though is that working in a corporate environment is not boring. A lot of crazy things happen, and as stupid as they seem, there's generally an underlying logic to how things work. Any system--technical or organizational--represents a set of tradeoffs and as an engineer I find it really interesting to reflect on the reasons things work the way they do in organizations. Engineers can make important non-technical contributions to their organizations if they can apply their penchant for understanding large systems to organizational systems.

Answer 12

Lots of good answers so far, and I agree with most of them.

Two main things that I don't like about the corporate development world:

1 - There is not a lot of ROI in a really polished product. If you are writing software for use in-house, there is no competition so if the UI is a little (or a lot) unintuitive, there are a number of annoying bugs, and the product is generally unpolished, it doesn't matter. The users can't switch, so it takes a real personal effort, if at all, to present a polished product.

2 - You're on the same network with a lot of non-technical and naive users, so things are generally more locked down. Our development organizations retains the ability to install software, and I think most do, but the user desktops typically don't allow them to, and the web filtering is more aggressive.

Answer 13

For me, the biggest challenge in being a corporate developer is to keep finding assignments that are interesting. Nowadays, most companies prefer to buy software rather than to build it in-house, so most of the work they want you to do is customizing commercial products, which ususally means dumbed-down work like the UI, implementing some interfaces, or building some shim to fill in gaps in the products. Well, I've been working as an IT developer for the same company for quite a while now, and since they have treated me quite well thus far, I can't complain really. How I've been able to keep it fresh all these years is by moving around a lot via internal transfers. So if you really want to work in the corporate environment, make sure there are real opportunities for lateral movement or else you might find yourself getting bored.

Answer 14

Developing software in a corporate environment can be a double edged sword in many respects, from my own experience I've found the following to have had the greatest impact on day to day life. This is by no means complete:

The Good

• The lines are blurred between roles, there's more opportunity for junior developers to have an impact on design and be involved much earlier in the process.
• You're often exposed to other areas of the company which allow you to gain knowledge, skills and experience you might not get in a pure development house (even if it is utterly terrifying to find out how payroll works).
• You're generally working on multiple projects at once.
• It's a great way to improve personal skills, especially when dealing with non-technical people.

The Bad

• You're a developer in a company that probably doesn't want to be developing (and paying for the development of) software.
• Nobody in the company has any idea what you do, but they're pretty sure it's your fault when something breaks.
• Projects and/or development cycles often end when the software "works", which is often much earlier than you would be happy with the quality of the software (which you now must support in many cases). I've found this to have a very profound effect on morale, good developers don't like letting bad code go out the door.
• Standards are lower for anything which is not public facing.
• Bureaucracy.
• It can be an uphill struggle to get appropriate tools and resources, I've found the "I bet if I were a coal miner and I asked for a bigger shovel, there wouldn't be a problem!" argument to be effective!
• Scope creep.

Answer 15

In my world (internal tools development for almost the entire company, a few hundred people), you get (in)famous quickly. Since you're working with everyone, everyone knows you and you're the go-to guy for a lot of things. Which can be good and bad...good in the sense that, if you're good, it opens up a lot of avenues for you to keep your ear to the ground and know the heartbeat of the business, and act as a hub for getting things done. Bad in the sense that sometimes you can get overwhelmed.

Another pitfall can be the politics that go into it - since your customers are internal, people can go up the chain and force work back down it if they have something they want done nownownow. And if you're not doing it fast enough, they can bring it straight to your manager.

If you're worried about being viewed as a cost center, see if you can lead initiatives to affect the bottom line of the business in tangible ways, like developing tools that automate menial work for departments and improves their turnaround by X%. Don't have a way to measure that? Introduce workflow tools that allow metrics reporting. Managers love metrics. I personally love the idea of drawing out the intricate business workflows on a high level, and then coding tools that implement it in a concrete way.

Since communication about requirements and development isn't tied to a contract with a third party, sometimes people can take awhile getting back to you.

One of my favorite aspects, depending on team size, is that I turn into a jack-of-all-trades and learn multiple skillsets, from being a DBA-lite to building a server from scratch onto which I can deploy the solutions I code out, to networking skills. YMMV, depending on how regimented the team is.

Answer 16

The hardest challenge is making people understand what you do. A lot of people still have huge gaps of knowledge about computers, especially the development of software. A lot of the time they also just don't care to know either. After a few years of development on a medical records application, one doctor was frustrated at how long it was taking and asked "Can't we just go to Staples and buy this?" If only it was that simple.

Having a manager that knows and fights for what you're doing is priceless.

Answer 17

I know you asked about challenges, but I thought I would add some of the benefits you can get in this environment.

The single, biggest benefit is that you have incredible access to your end users - they work down the hall! Additionally, you have complete access to their corporate culture.

You know who will be using your software, and what they are trying to achieve with it. I imagine it would be very hard to get this degree of insight if all you know about your users is what IP address they connect to your website from.

Another benefit is that you may get to work on other parts of the project, rather than just coding. Gathering requirements from stakeholders, run presentations for staff, and if it is a system that clients of your firm will be using then you may get to meet them and get another perspective on the business.

All of this exposure increases your knowledge of the business domain, and can make you a better developer.

Disclaimer - I've worked in the environment you describe for 10+years at the one law firm. It took a while to adapt but I'm enjoying it.

Answer 18

Outstanding answers so far. Allow me to throw in my $.02.

Our situation is unique in that we are an internal IT/Software Development department for a company whose main line of business is not software, but the software that we write is not used internally. Instead, our software is used as a value-added service on top of the physical products we sell. The software, then, is viewed as a selling tool, and not really a product on its own.

We get a lot of the good side-effects that others have mentioned. As a developer here, you do get to wear a lot of different hats. You get to work on lots of different projects using lots of different technologies, which is fun and gives you a wide breadth of experience. You definitely get to work on your soft skills, as you work with a lot of non-technical people.

However, we do experience the bad things as well. Since non-technical senior personnel prize managerial skills more than technical skills, there really is no career path for someone who wants to go the "Architect" route as opposed to the "Program Manager" route.

Another negative side effect is that you end up working in a department that isn't managed by technical managers, and a lot of your coworkers may not even be programmers by trade. That can be a good thing in some cases, because if you're a good programmer with good soft skills, you can have a very positive impact on your surroundings.

Unfortunately, the reality is that you often find yourself up against some very bad decisions made by non-technical people. That's almost any company, of course, but it's especially bad when even your fellow programmers aren't technically proficient enough to understand why some things should be done a certain way. You'll come across some very wrong-headed decisions with no real way to change them, no matter how obviously backwards it is to you.

IMHO, working for an internal IT department is a great decision if you're more the "duct tape programmer." If, however, you're more the architect or lead developer type, then you'll find yourself outgrowing an internal IT department after a few years of spinning your wheels against bad decisions and sloppy coding practices.