Programming productivity refers to software development issues and methodologies affecting the quantity and quality of code produced by an individual or team. Key topics in productivity discussions have included:
- Amount of code that can be created or maintained per programmer (often measured in source lines of code per day)
- Detecting and avoiding errors (through techniques like Agile Software Development, six sigma management, zero defects coding, and Total Quality Management)
- Software cost estimation (cost being a direct consequence of productivity)
The relative importance of programming productivity has waxed and waned along with other industry factors, such as:
- The relative costs of manpower versus machine
- a substantially less expensive global workforce is available via the Internet
- 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 be 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 provided to the programmers 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 becoming 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 development methodologies andsoftware development tools were promulgated, often championed by independent consultants brought in as troubleshooters on critical projects. The U.S. Department of Defensewas responsible for much research and development in this area, as software productivity directly affected large military procurements.
In those days, large development projects were generally clean-sheet implementation of entire systems, often including their own system-level components (such as data management engines and terminal control systems). As a result, large organizations had enormous data processing staffs, with hundreds or thousands of programmers working inassembly language, COBOL, JOVIAL, Ada, or other tools of the day.
Modern computer use relies much more heavily on the use of standardized platforms and products, such as the many general-purpose tools available today under Linux and the Microsoft operating systems. Organizations have more off-the-shelf solutions available, and computer use is a basic job requirement for most professionals. Tasks that once would have required a small development team are now tackled by a college intern using Microsoft Excel. The result has been a trend toward smaller IT staffs and smaller development projects. With larger projects, techniques like rapid prototyping have shortened development project timelines, placing a priority on quick results with iterative refinement. Traditional programming-in-the-large has thus become rare – the domain of industry giants like Microsoft and IBM. As a result, although programming productivity is still considered important, it is viewed more along the lines of engineering best practices and general quality management, rather than as a distinct discipline.
A need for greater programmer productivity was the impetus for categorical shifts in programming paradigms. These came from
- Speed of code generation
- Approach to maintenance
- Emerging technologies
- Learning curve (training required)
- Approach to testing
Source :http://en.wikipedia.org/wiki/Programming_productivity
Productivity Tools for Programmers
Hardware
Buy the best hardware that will make your workflow as optimized as possible. For some this may mean a 11″ Macbook Air they can take on the plane, for others it will be dual 27″ monitors connected to a quad-core desktop loaded with RAM and SSDs.
It will also mean having enough hardware for builds, staging, and other non-dev environments. Nothing kills productivity faster than waiting a day for the build to go green.
Software
Pick a text editor/IDE and become good at it. Learn to type at a decent speed, and learn the keyboard shortcuts and commands that will let you perform trivial coding tasks. On a similar note, learning a few common command line utilities for file searching will greatly decrease your downtime when not furiously adding lines of code.
Figure out the right communication tools between developers (and QA + product + design) is important too. Version control is standard nowadays, but also avenues for code reviews, discussions, and a wiki for keeping around tidbits of info. Project and bug tracking is necessary to capture actionable work, and I’ve found agile-style daily syncs with weekly emails a good balance of understanding the context at a local and company level.
People
Okay, so this stretches the definition a bit, but meetings, distractions, and constant project churn absolutely destroy productivity. Meetings, most will learn to manage themselves and schedule them together or block out coding time. Some programmers like coding with headphones, but earplugs also work, and it’s not unreasonable to have a relatively quiet, distraction-free work environment as well. As for project work, let your manager or project person understand the conditions for optimal development.
Know Yourself
Everybody codes slightly differently. I’ve found rigid solutions like the Pomodoro technique to not work for me; and while some can stay in the zone for hours, I find going 1-3 hours of work followed by a break works well for me. That feeling where you’re mostly-burnt-out and half-mindlessly-coding is one step beyond where you want to want to be at the end of the day.
It’s no coincidence that top software firms measure results more than hours, and let their developers manage their own schedules and projects. People who make it into these companies have largely figured out how their workflow is structured and it wouldn’t make sense for the company to disrupt that productivity.
Source: http://allenc.com/2013/03/the-best-productivity-tools-for-programmers/
Walang komento:
Mag-post ng isang Komento