views:

1008

answers:

13

I am wondering how do people develop programs in a software company? Like do they split up the work or does one person do everything. and how does it all work together? Hope you understand what I am talking about

A: 

This question seems way too general... it depends on the type of software being developed, this size of the team, the calibre of developers in the team etc. Are you applying for a job, or are you part of / leading a team and looking for ways of improving it?

Jesse Pepper
Coding Part How are they split by programmer?(etc: Functions) I am currently in school majoring in computer science - and hopfully move on to embedded software. since there are alot of proud programmers on this blog dedicated to what they like i wanted a professional answer to get me started.
Silent
+1 to counter drive-by downvote
Steven A. Lowe
+1  A: 

They all huddle up together (like a scrum in rugby) and smash their keyboards until they come up with lines and lines of code. They then compile the code, and a miraculous program is born.

Jobo
Up voted for nice use of sarcasm :)
javamonkey79
+3  A: 

Its pretty contextual.

From what I have seen it depends on:

  • The size of the company.
  • Whether the shop is in house or on its own.
  • What the product(s) are.

If the project is large enough then it will almost always have to be split up in some way shape or form.

Additionally, it seems to be a consensus that all projects are known by more than one dev thereby avoiding the 'hit-by-bus' scenario's.

javamonkey79
While it would seem on first thought sensible to avoid the loss of knowledge of one developer in the 'hit-by-bus' scenario, this will often turn into a cost/risk assessment. If the product developer is unavailable, how long until you have somebody who can, how much to get it, how much you make.
Greg Domjan
+1  A: 

It's a very general question, not all software companies work the same way, but if you want to get an idea I think any decent software shop can pass the Joel Test.

CMS
+2  A: 

There are so many ways I don't even know where to start.

Well, software development processes are a wide field in computing, please take a look at this wikipedia article and you will get a picture.

Waterfall and Spiral models are the classic.

Personally, I like to use "The best of all worlds" trying to focus on agile development, but maybe that's because I work on small-medium projects. XP and SCRUM are very good ways to think about software development.

There are many others, I just wanted to give you a snippet.

Ricardo Acras
+4  A: 

I presume the main thrust of your question is how do multiple developers work together on the same product.

When more than one developer works on a piece of software, typically one or more of these people will adopt the role of "software architect". These people focus on breaking the application down into discrete, logical units or areas of functionality (for example, "display engine") and define at a high level how these components should interact. Then the developer or team of developers working on a given area will break the requirements into smaller programming tasks until they can be measured in hours or days.

A good software team will typically focus on the "core" functionality of an application first - for example, a word processor should have some kind of input area for text, and save/open functionality. Once that is in place, refinements and enhancements are added incrementally by different teams working simultaneously around a commonly-understood core.

Rex M
A: 

I think the answer is... it depends. There are MANY ways to develop software in an organization. It breaks down into a couple of kinds

Code and Fix: This is where you're coding furiously now and fixing all the problems you have later. This can include a development process, but may not. This is a shop that has its share of "Cowboy" coders - those that think they can do everything, may like to reinvent the wheel, e.g., writing their own linked list implementations or something similar.

Process-based: This is an organization or team that recognizes the importance of following a standard process of Software Engineering. They realize that requirements, design, and documentation are important parts of the software development lifecycle.

I would strongly recommend you read Code Complete

jdt141
A: 

I believe their is a cauldron, some chicken bones, and duct tape involved. At least that's how we created our ERP system... ;-)

A: 

some companies follow the Extreme Programming (XP) agile techniques. and yes it depends on the size of the company. some companies that are small can handle it without XP. I know a company who does software the old-school style. :-)

jerbersoft
+6  A: 

Your question is very general.

If there's more than one person on the team, though, they almost always use a version control system which allows them all to work on one large program without getting in each other's way. One of the main jobs of a version control system is to merge the changes that each programmer makes into one big program with all their contributions together.

Joel Spolsky
It surprises me for you not to mention a bug tracking system.
Ngu Soon Hui
That's because Joel never needed a bug tracking system :/
Camilo Martin
A: 

The best answer is "it depends." It depends on (a) the workplace, (b) the client, (c) your relationships with your co-workers, (d) the skill levels of you and your co-workers, and (e) the business environment. There are easily a dozen more things that influence it, but those seem to be the top five.

Generally speaking, engineering is a team activity with work that gets divided up and parceled out. This means software engineers have to have fine communication skills in order to coordinate their activities with each other.

I would stringly suggest reading The Mythical Man Month by Fred Brooks, Code Complete by Steve McConnell, and The Pragmatic Programmer by Pragmatic Programmers LLC. If you only have time to read one, read Brooks; but if you're interested in software engineering as a profession, read all three.

A: 

Just making an assumption about your question.

Other than paired-programming, you'll probably want to find a way to prevent duplicated effort on the same code/area of the application. Here are some ways to split the work:

  1. Area of Expertise: a DBA may work on the database, a more experienced/senior programmer on the complex parts, core libraries, etc. Another person may do the user interface.
  2. Structure of the application: one person/group works on the workflow engine, another on the reporting module, a third on some B2B interface.
  3. Workload: who needs something to do?
  4. Random selection

Not saying these are good or bad ways of doing it.

Jeff O