Content deleted Content added
m Reverting possible vandalism by 199.52.13.101 to version by Oleg Alexandrov. False positive? Report it. Thanks, ClueBot. (639248) (Bot) |
expanded the stub; suggested need for metrics; suggested need to look at hardware and software environments as enablers of programmer productivity. |
||
Line 8:
* The relative costs of manpower versus machine
* a substantially less expensive global workforce is available via the Internet
(examples: http://www.wired.com/wired/archive/12.02/india.html?pg=7
http://www.wired.com/wired/archive/12.02/india.html)
* The size and complexity of the systems being built
* Highly publicized projects that suffered from delays or quality problems
* Development of new technologies and methods intended to address productivity issues
* Quality management techniques and standards
* apathy may be a factor (productivity needs to be a goal)
A generally accepted working definition of programmer productivity needs to be established and agreed upon. Appropriate metrics need to established. Productivity needs to be viewed over the lifetime of code. Example: Programmer A writes code in a shorter interval than programmer B but programmer A's code is of lower quality and months later requires additional effort to match the quality of programmer B's code; in such a case, it is fair to claim that programmer B was actually more productive.
Hardware aspects of programmer productivity
It is unfair to measure programmer productivity without factoring in the software and hardware tools that have been providing to the programmer's being measured. Example: a programmer with two displays is likely to be more productive than a programmer with a single display. With solid state drives becomming less expensive, one's hardware can be fine tuned for faster compilation as is required by new development paradigms such as TDD (test driven development).
An extensive literature exists dealing with such issues as software productivity measurement, defect avoidance and removal, and software cost estimation. The heyday of such work was during the 1960s-1980s, when huge mainframe development projects often ran badly behind schedule and over budget. A potpourri of [[software development methodology|development methodologies]] and [[software development tools]] were promulgated, often championed by independent consultants brought in as troubleshooters on critical projects. The [[U.S. Department of Defense]] was responsible for much research and development in this area, as software productivity directly affected large military procurements.
Line 34 ⟶ 44:
* ''Programming Productivity'', [[Capers Jones]], Mcgraw-Hill, 1986. ISBN 978-0070328112
* ''Estimating Software Costs'', [[Capers Jones]], McGraw-Hill, 2007. ISBN 978-0071483001
Internet articles
* "Coding Horror: Joining The Prestigious Three Monitor Club" (December 2006)
http://www.codinghorror.com/blog/2006/12/joining-the-prestigious-three-monitor-club.html
* "Coding Horror: The Programmer's Bill of Rights" (August 2006)
http://www.codinghorror.com/blog/2006/08/the-programmers-bill-of-rights.html
* "Dual Monitors", Bob Rankin
http://askbobrankin.com/dual_monitors.html
"... studies I've read come to the same conclusion: having a dual monitor
in a workplace setting can increase productivity by 20 to 50 percent.
If you're a computer programmer, it should be obvious that having your
source code on one side and your program on the other side of a dual monitor display
would be very helpful. Other areas where a dual monitor setup are helpful include customer
service reps, web design, and creation of newsletters or PowerPoint presentations."
__________________________________
| |||