Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm interested in learning about any process you need to follow when coding for a large corporation.

For example, it would be nice to see a little insight into how you (or your manager) handles

  • Code reviews
  • Deployment to production
  • Procuring HW/SW for development
  • Evaluating vendors
  • SOX Compliance
  • Security reviews

... or anything else I may have missed. It would also be nice to see if you think there is any benefit to the paperwork, or if there is a comparable software alternative.

I'm interested in everything from paperwork, meetings, routines, or even software tools you may use.

share|improve this question

closed as too broad by gnat, Dan Pichelman, MichaelT, Kilian Foth, Bart van Ingen Schenau Sep 15 '13 at 14:56

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Could you clarify the purpose of the question? Are you asking for best practices, or what we have observed in large enterprise software projects ? –  user2567 Oct 22 '10 at 16:16
    
@Pierre I would think that an Enterprise would follow best practice but if that's not the case, do share. –  makerofthings7 Oct 22 '10 at 16:18
4  
No, large corporations often don't follow best practices. They have a setup that has worked for them so far, and they're reluctant to change. The closer software is to a corporation's main business, the better the processes will be in general. –  David Thornley Oct 22 '10 at 16:32
    
I don't see how this is a question. I see several possible interpretations: "Tell me about the things you put up with when you're working with a large corporation", "Tell me about the bureaucratic processes corporations use", or possibly "How do you cope with the bureaucratic processes in your company?" What exactly do you want to know? –  Evan Kroske Oct 23 '10 at 4:14
    
@Evan - I'd like to learn about effective processes, checklists, that can be replicated in other companies to deliver quality software products –  makerofthings7 Oct 23 '10 at 22:21

6 Answers 6

up vote 3 down vote accepted

If I'm getting the question right, SDLC is the answer you're looking for.

The Systems development life cycle (SDLC), sometimes referred to as the Application development life-cycle, is used in systems engineering, information systems and software engineering, and represents a process for creating or altering information systems, and the models and methodologies that people use to develop these systems.

The Systems development life-cycle is a methodology that also forms the framework for planning and controlling the creation, testing, and delivery of an information system.

The Systems development life-cycle concept acts as the foundation for multiple different development and delivery methodologies, such as the Hardware development life-cycle and Software development life-cycle. While Hardware development life-cycles deal specifically with hardware and Software development life-cycles deal specifically with software, a Systems development life-cycle differs from each in that it can deal with any combination of hardware and software, as a system can be composed of hardware only, software only, or a combination of both...

http://upload.wikimedia.org/wikipedia/commons/thumb/7/7e/SDLC-Maintenance-Highlighted.png/240px-SDLC-Maintenance-Highlighted.png

share|improve this answer
    
It's in the right direction; but I'd like to find roles, responsibilities, and details. For example, SOX may have requirements saying the dev can't deploy directly to production. A checklist saying: "Always check-in code before deploying, or source your build from Source Safe/TFS, etc."... something detailed and anal like that would be perfect. –  makerofthings7 Oct 22 '10 at 16:27
1  
@MakerOfThings7: I would have loved a checklist like that that was enforced at the bank I contracted for once. –  David Thornley Oct 22 '10 at 16:33

Throw it out there and hope it sticks from what I have seen in many places.

share|improve this answer
1  
Why is it that the honest truth like this cracks me up, and yet also makes me so sad? –  makerofthings7 Oct 22 '10 at 16:43

I've seen many different way of working, but in most case, there is a responsible for everthing.

  • One team responsible of deployment
  • One team responsible of analysis
  • One team responsible of coding
  • One team responsible of database management
  • One team responsible of documentation
  • One team responsible of reviews
  • One team responsible of architecture
  • One team responsible of hiring
  • and so on...

Of course you have a responsible of the responsible team, and of course a reponsible of responsibles, and often responsibles of responsibles of responsibles...

Everyone has send a written request to the other responsible for anything. Some organization even invest in heavy and complicated workflow systems.

Since everyone is evaluated on his personnal performances, and that's the only way to get promoted or get a salary increase, everyone try to protect themselve from external requests and make choice based on how they will be evaluated.

It's almost impossible to have a successful software project in such organizations. (success = in time and in budget).

It is also an environment where a decent programmer wouldn't work in.

I've been able to improve some of the problems by implementing Scrum and other agile like methodologies such as Scrum, Lean, XP... So that's my answer:

To solve most large enterprise weaknesses, agile is a best practice

share|improve this answer

Really there should be no difference between the procedure you follow where ever you program.

So you should be doing:

  • Code reviews
  • Using Source Control
  • Continuous/Nightly builds
  • Automatic deployment to test servers
  • Strict procedures when deploying to production servers
  • etc.

These things will make your development process run smoothly where ever you code.

With larger organisations there might be more paperwork.

This could cause difficulties as you have to go through more layers of bureaucracy to get hardware and software purchased. In this case you have to be absolutely certain about what you want, why you want it and what advantages it will bring to the company.

share|improve this answer
    
I suppose I'm looking for samples of bureaucratic paperwork! (or ideas on how to structure effective paperwork) :{ –  makerofthings7 Oct 22 '10 at 16:28
    
@MakerOfThings7 - I don't work in a large organisation at the moment so I don't have any examples and I've blanked from my mind the hoops I had to jump through at places where there was ;) –  ChrisF Oct 22 '10 at 16:31
    
Sorry to bring those memories to your mind! Hopefully you're in a much better environment now. And on a related note, I am starting to think my tie is feeling more like a leash these days. –  makerofthings7 Oct 22 '10 at 16:34

The main differences I've experienced is that sometimes policies will be applied at the corporate level without consulting everyone at the bottom (such as what version control system to use, or what bug tracker to use), and there's often more complex release procedures.

But that's about it. The development process is pretty much whatever the team uses - sometimes large companies will use agile processes sometimes they won't. Same goes for smaller companies.

share|improve this answer

We have dedicated teams for provisioning, DBA, windows, Unix, test, networks, security, change management etc,

However, at the code monkey level we try for Agile and combine analysts with shopfloor architects with developers.

This works for us because we focus on a given business line with in depth knowledge, but the DBAs for example manage all 1000s of servers for all businesses with only superficial knowledge of each.

The "bureaucratic" cuts both ways:

  • does it make sense to have 200 code monkey teams buying their own servers and installing them with their own standards?
  • who the hell do I speak to find out how to set up a server inside this firewall with that config etc?

Consistency is king: I can run my app on any web of DB server in the organisation but lordy it's annoying at times.

share|improve this answer

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