Major software: concept >> release

I find it sorta interesting cos I know nothing about it, how a major release is made. Lets take for example, um, photoshop. I wonder how the program's many functions are worked out, who gets given what task and how many levels there are in the project. I imagine that there are programmers who are told to make code that has x inputs, does such and such to the data and has this output, and they have no idea where their code gets used, and many levels up there are people drawing flow diagrams of what happens.
How is a project like that managed, how many levels are there in the organisation and how many people are typically involved? Does anyone have a fair idea of the entire package and all its code or is it totally a team effort with not one person knowing any one part?

Someone wanna explain how such software makes it to the shelves, or is the a too big a question? I dunno enough to get more specific. I dunno why I find it interesting i just do.

i think it really depends on what kind of software, and how big the project is.Operating systems like windows have 100's of people.

You gotta remember in most programmes you are going to need people working on kernels,interface,graphic design,sound,scripts etc....
you have specialists in certain fields and some people that can do multiple tasks so really you can have a large range of people

Who coordinates all those parts working together? An old flatmate works at a large voice over ip company and would sometimes mention how many of the programmers didn't have the faintest idea how to operate the stuff they produced. Kinda fascinating. I suppose you one could compare it to the efforts of different parts of Boeing making the same 747 yet none of them can fly it...

I would say a head of design, like bill gates was to windows 95.
someone who knows wat he wants as the end product, and knows enough about each aspect to know wat groups he needs and wat he needs from them

100's? Microsoft has literally thousands of people, and we're not only talking a few thousand working on Longhorn and associated products... let alone those that are still working on existing OSs... A good devel team of maybe 10 people would keep Photoshop running nicely including 3 or so architects and 'big picture' people. Adobe will have more like 30 - 40 that work on all products at a time...

There are as many ways to run a project as there are projects to run....

take open source... the 'traditional' open source approach is to have one or two people who co-ordinate the project (more in bigger projects), and anyone with an interest in doing so can submit patches adding feature they want, or fixing bugs they've found. The co-ordinaters then decide whether they include the patches into the main release or not. So pretty much anyone who contributes will have a wide understanding of the project, not just the part that they're working on (although they don't necessarily understand all the details).

I think you'll find that its more like about 400 people worked on photoshop 7.

for example - 5 people worked on the "save for web" function... alone -
8 people on the interface - etc etc

if you have photoshop check out the credit list - its massive..

Adobe At-a-Glance

Headquarters: San Jose, Calif
Fiscal 2003 revenues: $1.295 billion
Fiscal 2003 earnings: $266.3 million
Founded: 1982
Employees: approximately 3,500 in 26 offices around the world
The best high-tech company to work for in America (FORTUNE magazine, 2004)

There we go... I under-estimated the unproductivity of the rest of the world.

Not suprisingly more software development projects fail then succeed.

Imaging back in the old days when OO programming wasnt around!!

you're not really answering smiley's question so here goes...

Smiley you have what is known as an SDLC (software development lifecycle) that any project be it $50,000 or 180 million will adher to.

These phases in the standard waterfall project methodology can generally be stated as

Business Case - Why do you want it, how much will it cost, what is the roi ?

Business Analysis - A system independent definition of exactly what the business requirements of the system are

Design - high level and low level, specific the architetural principles to be used, the development to be done and further break this down to low level design where you are getting into the functions etc.. needed to meet the high level design which in turn should meet the business requirements

Development - this is the actually cutting of the code to develop the project, can be 1 to 1000 programmers doing this

Testing - Once development has been completed a thorough set of testing will be done to verify that the solution functionally works but also meets end user requirements (there are multiple phases of testing overlayed on top of each other)

Deployment - Once the development has been signed off from the testers it needs to be deployed or in the case of photo-shop shrink wrapped

Generally you will have a project manager overseeing all of these phases to ensure all of them are meeting targets / schedules etc... In the case of photo shop you would have mutiple project managers managaing different areas or different small chunks of development (each going through the SDLC) overseen by a program manager or PMO (program management office)

Also running concurrently over the top you will have qulaity assurance which is looking to trap potential defects in the phase of the SDLC it occurs in so that it doesn't translate into a defect in testing..

Thats a real highlevel overview, If you want further info or this broken down feel free to ask

Then beyond that you have your version control. And patches to exisiting software etc.

sorry sneak, but that's mostly rubbish. The SDLC is used by a lot of big companies, but the amount they adhere to the text book definition varies greatly. Very few find that a rigid design methodology (which is what a lot of people interpret the SDLC as) to be of much use. In the end, the project time tails out to ridiculously long lengths, and the problem tends to change too much in that time. You end up backtracking way too much (for the record, the SDLC is not a 'waterfall' method... phases overlap, and you have to backtrack when things change).

Still, they list to teach us this sort of thing in Computer Science (or other) degrees. It's fine as a theory, and it provides a fairly generic structure to create more flexible, taylor made methodologies.

Having said that, there are plenty of companies (and not just mickey mouse, one man bands) who use methodolgies that don't really reference the SDLC, but are still successful.

Heh, I remember lecturers in Info Systems papers in a BCom being very much into preaching the SDLC ...whereas Computer Science lecturers used to state that it was all fine and well, but rarely worked in reality.

Usually the most finely laid plans are disrupted by what customers want and their changing requirements.

Whether they adher to it or not is a different thing...

Mutant that is based upon nine years in the industry across 5 different companies (two of them IBM) and FYI I don't have a degree in computer science

Whether you want to call it SDLC or not any company worth there salt will follow something like this (ever looked at CMM or IEEE its all based on this stuff) and it is a waterfall project management methodology (even if the phases do overlap) because you will have gating from one phase to the next

Also you don't have to backtrack if you get each phase right which my friend is what the new emerging dicipline of quality assurance is all about... then you find you have time cost and quality all increasing in each subsequent release as a project improvement loop is created and the process is streamlined..

So i think i'll make the rubbish call on you

however if you want to quibble i will allow that iterative approaches based around prototyping and some RAD appraoches do work especially in the web space...

But large scale enterprise apllcation development will follow an SDLC as I would expect most microsoft projects to as well

That's not quite what I am talking about. Have you ever worked in a smaller business? Where you don't have the economies of scale and a large customer base?

do the linux developers follow the SDLC?

Can you furnish an example of what you are talking about ?

I suspect what you are talking about is symtomatic not of size but rather the maturity of the companies development processes

ie can an end user change the goal posts on you halfway through development and is this to be expected...

I'm not sure, would be interested to understand what there methodology is though given the constraints of waht they are producing..

I'm not here to fight or defend an approach but am keen to learn

Nah, don't really have the time to explain on here (funnily enough I happen to building a new patch release of some stuff for several platforms at the moment) ...ask me when you see me out and about.

Yes. They follow a form of development cycle. Anyone can subit code changes and bug fixes etc, but it is still all controlled fairly centrally as to what actually goes into the final releases.

Yeah I figured that out re-reading mutants post early up to which I would point out that this isn't enterprise application development nor is that type of development centred around what smiley was asking about.

well, see that's the problem I have... the SDLC is not the only way of doing things, regardless of the size of the project... you seem to believe that once a project reaches a certain size, it's only viable if it uses the SDLC

the linux developers use a life cycle, yes, but they do not use *the* SDLC. If you want to define any sort of lifecycle as the SDLC, then yes, I agree, pretty much everyone uses some variation of the SDLC. It's so generic, and so common to any sort of engineering, that it's hard not to. But they also break a lot of the rules of the SDLC, and add stuff in, etc. So much so that although on a theoritical level it can still be related to the "template" of the SDLC, it's no longer the text book definiton of the SDLC.

Calling every life cycle the SDLC is about as useful as saying "all good projects have a methodology"

first of all I aint saying shit about your 'text book' defintion because I haven't learnt it from a text book. The sdlc is something i have learnt in the industry spanning upwards of 30 projects now some as little as $10,000 to the current one i'm budgeted at about $180 million k ?

Next the linux developers aren't developing commerically applicable software to meet a set of end user needs, the are creating open source when everyone is contributing and central people are deciding whether these contributions are of use or not...

SDLC in my definition is any methodology that has a requirements / design / build / test / deployment phase.

So let us say I am a big commercial customer and have software I need built and come to your development house. I am curious as to which one of the above phases you would leave out in your 'other' methodologies ?

Barring of course RAD approach and prototyping (which in any case has all of the above, just in abbreviated format)

Please do enlighten me

Not entirely true. I would say the development and features is being driven somewhat commercially. What with Oracle using linux as their core development environment. And with HP, IBM and Sun all getting heavily involved now.

Sneak: What are your thought's on XP? ...and no I don't mean the operating system, I mean eXtreme Programming.

sneak, yes, well that was basically my point in my last post.. if you generalise the SDLC to that, then yeah basically everything uses it. It's almost impossible not to use it..

I would say RAD is the other major methodology used in industry. This tends to be the OSS philosophy ("release early and often").

Hey Harvey... I think XP has its time and place and can work well for small development especially in the web space.

afterall if you know exactly the requirement you are trying to meet, can be resonably assurred of cutting good code and you have a tester / qa there who can understand what you're doing and can test at the same time its brilliant for the 'speed to market' factor it has going for it...

however not sure how well it works as soon as the development becomes larger and where you have distributed teams working on different parts.

How is it all brought together ? Would be interested in the process behind it ?

have you guys heard of PEBT ? (package enabled business transformation) that is the methodology we're following at the moment where you are implementing large off the shelf software (say a crm) into an existing businesses architecture. Really interesting it throws everything on its ear..

The RFP becomes the most important part (almost your requirements) you select the best package and then you look to change your business processes to meet the packages vanilla flavour because it is considered best of breed...

Where my current company fucked up is they didn't bassline current legacy system processes, so while we might be using the best of breed packages how do we know its configured to cover all the quirky system processes our current architecture performs ?

I'm not looking forward to UAT

Ahhh, the good ole legacy systems. I've worked with a group of people that have spent a number of years now working on bringing a large legacy system into the new millenium. It's all come together quite nicely now. Runs on multiple platforms and supports the major databases at the backend and is now in production environments in some large companies here and around the world ...will tell you about it sometime if you like ...but not on here as I don't like going into the specifics of my job and who I work for etc in forums.

yeah dude we should do that, always interesting to chat with someone doing much the same stuff and the eternal question do you upgrade the legacy or do you replace with a new system bound to be more flexible if you can get it to do what the current system does ?

What I love about legacy systems is the quick and dirty bandaids put in by some contractor who never docmuented it and which nobody has any idea about...

When i was working on telstra NPAMS system in australia (Which tracked all the laid cable into telephones) they put in a change and put out of action half the gas pipes in the northern territories

Nobody could even explain why they were hooked into the system...

S

I meant to come back and post thanks to everyone for giving me some insight but forgot. Um, thanks

Now I'm a pain for dredging the thread up...