Why should developers spend their time making pointless alterations to standard code, when all that does is change how something looks, rather than focusing on core functionality?
Ah, good ol' "developers should focus on X, not Y!". I can assure you that's not how it works. Some developers focus on X, and others on Y. One is not a priority over the other.
Ah, good ol' "developers should focus on X, not Y!". I can assure you that's not how it works. Some developers focus on X, and others on Y. One is not a priority over the other.
Yeah, but you could still have either all developers focussing on Y to increase quality of core functionality, or you could not employ the developers working on X and have a cheaper product, more profit or both.
Yeah, but you could still have either all developers focussing on Y to increase quality of core functionality, or you could not employ the developers working on X and have a cheaper product, more profit or both.
Presumably you agree there must be an optimum number of developers for a particular project. How long would OS X take to develop if only one person was doing it?
I haven't read the book, but from that wikipedia page, the main problem that it is highlighting seems to stem from what happens if you try to add programmers to a project that's already started.
I'm talking about never doing a particular part of a job (don't bother changing the appearance of OS provided UI widgets). If the time taken to do that job cannot be fruitfully used elsewhere in the project, then don't pay for that time, and make more profit.
Presumably you agree there must be an optimum number of developers for a particular project. How long would OS X take to develop if only one person was doing it?
At some point, depending on the conceptual complexity of the system, communication concerns (training, meetings, etc) swamp any gains you'll have by bringing new coders on board. This is established, proven, and common sense.
The optimal number is that number required such that the abstractions in the design at the various levels can each be considered in whole by an individual. Too many people, and the cross-communication becomes the main task. Too few people, and there's too much to keep in one's head to work effectively. You're right that there is a balance, but for a well designed system, it's frightfully small. For a poorly designed system, it will be larger, but even then there is a maximum limit to the number of people who can interact effectively on the project. This is compounded in most cases by those poorly designed systems also having a poor set of abstractions, requiring *more* cross-communication that would normally be necessary, and you have a fundamental problem: you can't reach the minimum people needed for conceptual integrity without exceeding the maximum number of people for communication overhead to be less than the coding effort.
Quote:
I haven't read the book
Every programmer or manager of programmers should.
Quote:
, but from that wikipedia page, the main problem that it is highlighting seems to stem from what happens if you try to add programmers to a project that's already started.
I'm talking about never doing a particular part of a job (don't bother changing the appearance of OS provided UI widgets). If the time taken to do that job cannot be fruitfully used elsewhere in the project, then don't pay for that time, and make more profit.
So in other words, take those programmers and move them from the portion that isn't worth it, and adding them somewhere else on the project.
Which has already started.
Same problem, bub. The only options you have are to move them to another *NEW* subproject, which hopefully will be more fruitful, or to lay them off, if profits are your main goal.
Presumably you agree there must be an optimum number of developers for a particular project.
Yes, and presumably, Apple has already found it for iTunes.
Quote:
How long would OS X take to develop if only one person was doing it?
Too long.
Quote:
I haven't read the book, but from that wikipedia page, the main problem that it is highlighting seems to stem from what happens if you try to add programmers to a project that's already started.
I'm talking about never doing a particular part of a job (don't bother changing the appearance of OS provided UI widgets). If the time taken to do that job cannot be fruitfully used elsewhere in the project, then don't pay for that time, and make more profit.
You were suggesting that having more people focus on one thing would get that one thing finished faster. That's false.
You were suggesting that having more people focus on one thing would get that one thing finished faster. That's false.
No, it is not necessarily false. That's why I asked if you agreed that there was an optimum number of people to work on a software project, and cited the ridiculous notion of one person programming OS X.
Clearly, having more than one person programming OS X results in OS X being developed faster.
We have also not considered the possibility that the people who worked on the iTunes UI widget appearances may have had other tasks to do. If those people did not do the widget alteration, their other tasks would have been completed more quickly. Whether that would accelerate the whole project or not is unclear.
So in other words, take those programmers and move them from the portion that isn't worth it, and adding them somewhere else on the project.
Which has already started.
No, in my scenario, the project has not already started. It is at the planning stage that the decision to alter OS UI widget appearance is not made. Therefore the task is never allocated, and no-one is moved after the project is started.
No, it is not necessarily false. That's why I asked if you agreed that there was an optimum number of people to work on a software project, and cited the ridiculous notion of one person programming OS X.
Clearly, having more than one person programming OS X results in OS X being developed faster.
That's because OS X consists of thousands of projects, all of which can be developed in parallel.
No, in my scenario, the project has not already started. It is at the planning stage that the decision to alter OS UI widget appearance is not made. Therefore the task is never allocated, and no-one is moved after the project is started.
So in other words, it has no relation to the iTunes project. Well, now that we have *that* cleared up...
I think you're missing the point. The lesson is: don't put too many people on a project. It doesn't matter if you are starting the project from scratch, or it's already started. If you put too many people on, then the time and energy spent simply coordinating them will be the majority of same spent. ie, a waste. Throwing more programmers at a project won't work.
I think you're missing the point. The lesson is: don't put too many people on a project. It doesn't matter if you are starting the project from scratch, or it's already started. If you put too many people on, then the time and energy spent simply coordinating them will be the majority of same spent. ie, a waste. Throwing more programmers at a project won't work.
No, I think that both you and Chucker are not getting that I really do understand good and bad ways to manage a software project, and that adding programmers to a project that's already started is almost certainly a bad idea.
It would seem that I haven't been explicit enough in what I'm saying, so here goes:
When I talked about "altering OS UI widget appearance", I was talking about the iTunes 7 project. I meant that when programming iTunes 7, they could have left the OS provided UI widget code alone so that iTunes was still Aqua, but they chose not to do that.
Assuming Apple follow a sensible model of software development, the iTunes 7 project should have gone something like (on a very simplistic level):
1.) Specify additional iTunes 7 features.
2.) Identify the tasks required in order to implement the additional features.
3.) Allocate the programming tasks to programmers.
Now, let's make some assumptions:
A.) That the tasks have been broken down as much as possible, such that only one programmer can realistically and/or efficiently work on them.
B.) That the iTunes team doesn't always hire or otherwise have at its disposal the optimum number of programmers.
C.) That the programmer(s) who was/were allocated the task(s) of altering the UI widgets were allocated other tasks.
D.) That the programmer(s) who was/were allocated the other task(s), were also allocated more than one task.
If assumptions A and B are correct, it means that C and/or D applies.
Now, the decision to alter the UI widget appearance would have used up time and effort in stages 1.) and 2.). This time could possibly have been used elsewhere in these stages (on better planning the new features or to plan additional new features), or just not done at all and therefore accelerated the planning stage.
In stage 3.), there will be a "critical pathway" of tasks.
i.) If the UI widget alteration is part of the critical pathway (unlikely), not doing it decreases the overall project time.
ii.) Otherwise, if assumption C applies, then if any of the "other tasks" the programmers were allocated are in the critical pathway, then not doing the widget alteration decreases the project time (because the programmers can spend all their time on the critical pathway task).
iii.) If ii.) is not the case, but both assumptions C and D apply, then if not all of the multiple tasks allocated to programmers of assumption D are in the critical pathway, the programmers who were allocated UI widget tasks could instead be given the non-critical pathway tasks of the other programmers, leaving the others more time to work on the critical pathway tasks, decreasing overall project time.
If none of these are the case, then the programmers allocated the UI widget alteration task could be used in other projects, or simply not be employed in the first place.
Whatever, I think it is reasonable to say that altering the UI widget appearance when there are more important issues (such as how much iTunes on Windows can suck) is a waste of effort and/or money.
It also makes little sense to me to say that iTunes is its own brand and has therefore been altered so it stands out in both Windows and OS X. Well, when it was Aqua, it also stood out in Windows, and there's no need for it to stand out in OS X because it has no competition on that platform. Additionally, Apple should want to strongly associate the Apple brand with the iTunes brand, in order to increase the "iPod halo effect". Right now, OS X is Aqua, and therefore Aqua is part of the Apple brand.
Comments
iTunes is in it's own little world because of Windows compatibility. They've always had their own widgets anyway.
All previous versions have supported double scroll arrows at both ends of the scroll bar.
Why should developers spend their time making pointless alterations to standard code, when all that does is change how something looks, rather than focusing on core functionality?
Ah, good ol' "developers should focus on X, not Y!". I can assure you that's not how it works. Some developers focus on X, and others on Y. One is not a priority over the other.
Ah, good ol' "developers should focus on X, not Y!". I can assure you that's not how it works. Some developers focus on X, and others on Y. One is not a priority over the other.
Yeah, but you could still have either all developers focussing on Y to increase quality of core functionality, or you could not employ the developers working on X and have a cheaper product, more profit or both.
Yeah, but you could still have either all developers focussing on Y to increase quality of core functionality, or you could not employ the developers working on X and have a cheaper product, more profit or both.
No. It doesn't work like that.
No. It doesn't work like that.
Presumably you agree there must be an optimum number of developers for a particular project. How long would OS X take to develop if only one person was doing it?
I haven't read the book, but from that wikipedia page, the main problem that it is highlighting seems to stem from what happens if you try to add programmers to a project that's already started.
I'm talking about never doing a particular part of a job (don't bother changing the appearance of OS provided UI widgets). If the time taken to do that job cannot be fruitfully used elsewhere in the project, then don't pay for that time, and make more profit.
Presumably you agree there must be an optimum number of developers for a particular project. How long would OS X take to develop if only one person was doing it?
At some point, depending on the conceptual complexity of the system, communication concerns (training, meetings, etc) swamp any gains you'll have by bringing new coders on board. This is established, proven, and common sense.
The optimal number is that number required such that the abstractions in the design at the various levels can each be considered in whole by an individual. Too many people, and the cross-communication becomes the main task. Too few people, and there's too much to keep in one's head to work effectively. You're right that there is a balance, but for a well designed system, it's frightfully small. For a poorly designed system, it will be larger, but even then there is a maximum limit to the number of people who can interact effectively on the project. This is compounded in most cases by those poorly designed systems also having a poor set of abstractions, requiring *more* cross-communication that would normally be necessary, and you have a fundamental problem: you can't reach the minimum people needed for conceptual integrity without exceeding the maximum number of people for communication overhead to be less than the coding effort.
I haven't read the book
Every programmer or manager of programmers should.
, but from that wikipedia page, the main problem that it is highlighting seems to stem from what happens if you try to add programmers to a project that's already started.
I'm talking about never doing a particular part of a job (don't bother changing the appearance of OS provided UI widgets). If the time taken to do that job cannot be fruitfully used elsewhere in the project, then don't pay for that time, and make more profit.
So in other words, take those programmers and move them from the portion that isn't worth it, and adding them somewhere else on the project.
Which has already started.
Same problem, bub. The only options you have are to move them to another *NEW* subproject, which hopefully will be more fruitful, or to lay them off, if profits are your main goal.
Presumably you agree there must be an optimum number of developers for a particular project.
Yes, and presumably, Apple has already found it for iTunes.
How long would OS X take to develop if only one person was doing it?
Too long.
I haven't read the book, but from that wikipedia page, the main problem that it is highlighting seems to stem from what happens if you try to add programmers to a project that's already started.
I'm talking about never doing a particular part of a job (don't bother changing the appearance of OS provided UI widgets). If the time taken to do that job cannot be fruitfully used elsewhere in the project, then don't pay for that time, and make more profit.
You were suggesting that having more people focus on one thing would get that one thing finished faster. That's false.
You were suggesting that having more people focus on one thing would get that one thing finished faster. That's false.
No, it is not necessarily false. That's why I asked if you agreed that there was an optimum number of people to work on a software project, and cited the ridiculous notion of one person programming OS X.
Clearly, having more than one person programming OS X results in OS X being developed faster.
We have also not considered the possibility that the people who worked on the iTunes UI widget appearances may have had other tasks to do. If those people did not do the widget alteration, their other tasks would have been completed more quickly. Whether that would accelerate the whole project or not is unclear.
So in other words, take those programmers and move them from the portion that isn't worth it, and adding them somewhere else on the project.
Which has already started.
No, in my scenario, the project has not already started. It is at the planning stage that the decision to alter OS UI widget appearance is not made. Therefore the task is never allocated, and no-one is moved after the project is started.
Every programmer or manager of programmers should.
Indeed. From the synopsis it would seem that it is full of good advice that could apply to pretty much any field of engineering.
No, it is not necessarily false. That's why I asked if you agreed that there was an optimum number of people to work on a software project, and cited the ridiculous notion of one person programming OS X.
Clearly, having more than one person programming OS X results in OS X being developed faster.
That's because OS X consists of thousands of projects, all of which can be developed in parallel.
No, in my scenario, the project has not already started. It is at the planning stage that the decision to alter OS UI widget appearance is not made. Therefore the task is never allocated, and no-one is moved after the project is started.
So in other words, it has no relation to the iTunes project. Well, now that we have *that* cleared up...
I think you're missing the point. The lesson is: don't put too many people on a project. It doesn't matter if you are starting the project from scratch, or it's already started. If you put too many people on, then the time and energy spent simply coordinating them will be the majority of same spent. ie, a waste. Throwing more programmers at a project won't work.
I think you're missing the point. The lesson is: don't put too many people on a project. It doesn't matter if you are starting the project from scratch, or it's already started. If you put too many people on, then the time and energy spent simply coordinating them will be the majority of same spent. ie, a waste. Throwing more programmers at a project won't work.
No, I think that both you and Chucker are not getting that I really do understand good and bad ways to manage a software project, and that adding programmers to a project that's already started is almost certainly a bad idea.
It would seem that I haven't been explicit enough in what I'm saying, so here goes:
When I talked about "altering OS UI widget appearance", I was talking about the iTunes 7 project. I meant that when programming iTunes 7, they could have left the OS provided UI widget code alone so that iTunes was still Aqua, but they chose not to do that.
Assuming Apple follow a sensible model of software development, the iTunes 7 project should have gone something like (on a very simplistic level):
1.) Specify additional iTunes 7 features.
2.) Identify the tasks required in order to implement the additional features.
3.) Allocate the programming tasks to programmers.
Now, let's make some assumptions:
A.) That the tasks have been broken down as much as possible, such that only one programmer can realistically and/or efficiently work on them.
B.) That the iTunes team doesn't always hire or otherwise have at its disposal the optimum number of programmers.
C.) That the programmer(s) who was/were allocated the task(s) of altering the UI widgets were allocated other tasks.
D.) That the programmer(s) who was/were allocated the other task(s), were also allocated more than one task.
If assumptions A and B are correct, it means that C and/or D applies.
Now, the decision to alter the UI widget appearance would have used up time and effort in stages 1.) and 2.). This time could possibly have been used elsewhere in these stages (on better planning the new features or to plan additional new features), or just not done at all and therefore accelerated the planning stage.
In stage 3.), there will be a "critical pathway" of tasks.
i.) If the UI widget alteration is part of the critical pathway (unlikely), not doing it decreases the overall project time.
ii.) Otherwise, if assumption C applies, then if any of the "other tasks" the programmers were allocated are in the critical pathway, then not doing the widget alteration decreases the project time (because the programmers can spend all their time on the critical pathway task).
iii.) If ii.) is not the case, but both assumptions C and D apply, then if not all of the multiple tasks allocated to programmers of assumption D are in the critical pathway, the programmers who were allocated UI widget tasks could instead be given the non-critical pathway tasks of the other programmers, leaving the others more time to work on the critical pathway tasks, decreasing overall project time.
If none of these are the case, then the programmers allocated the UI widget alteration task could be used in other projects, or simply not be employed in the first place.
Whatever, I think it is reasonable to say that altering the UI widget appearance when there are more important issues (such as how much iTunes on Windows can suck) is a waste of effort and/or money.
It also makes little sense to me to say that iTunes is its own brand and has therefore been altered so it stands out in both Windows and OS X. Well, when it was Aqua, it also stood out in Windows, and there's no need for it to stand out in OS X because it has no competition on that platform. Additionally, Apple should want to strongly associate the Apple brand with the iTunes brand, in order to increase the "iPod halo effect". Right now, OS X is Aqua, and therefore Aqua is part of the Apple brand.