riwu
2012-09-29 22:01:02
Just thought that i'd share this rather interesting article from
http://haacked.com/archive/2007/06/25/understanding-productivity-differences-between-developers.aspx
Below are some quotes (slight modification) that are can be useful for budding scripters ;)
http://haacked.com/archive/2007/06/25/understanding-productivity-differences-between-developers.aspx
Below are some quotes (slight modification) that are can be useful for budding scripters ;)
The best programmers are up to 28 times better than the worst programmers, according to “individual differences” research.
Well how in the world can one developer write code 28 times faster than another developer?
This sort of thinking represents a common fallacy when it comes to measuring developer productivity. Productivity is not about the lines of code. A huge steaming pile of code that doesn’t get the job done is not productive.
Good Developers Write Code With Less Bugs
I once worked with a developer who was praised by my boss for being extremely fast at writing code. He sure was fast! He was also fast at introducing bugs into code. His code was sloppy and hard to understand.
The key measure that wasn’t figured into his productivity measurement was the amount of productivity lost by the QA team attempting to reproduce bugs introduced by his code, along with the time spent fixing those bugs by this developer or other developers.
Everyone focused on his time to "completion", but not on the total cost of ownership of that code. Code is not complete when a developer says it is complete. That is not the time to stop the stopwatch. It’s when QA has had its say that you can put the stopwatch away for the moment.
As I like to say, productivity is not about speed. It’s about velocity. You can be fast, but if you’re going in the wrong direction, you’re not helping anyone.
Good Developers Write Maintainable Code (Good standards and script structure)
Hand in hand with writing less bugs is writing understandable maintainable code. As soon as a line of code is laid on the screen, you’re in maintenance mode on that piece of code.
Code that is brittle and difficult to change wastes hours and hours of developer cycles when trying to amend a system with updates and new features. By writing maintainable code, a good developer can make these changes more quickly and also improves the productivity of his or her team members who later have to work on such code.
Good Developers Do More With Less Code
Another hallmark of a good developer is that they know when not to write code. As a friend always tells me
Why build what you can buy? Why buy what you can borrow? Why borrow what you can steal?
With a few exceptions, the NIH (Not Invented Here) syndrome is a pathological productivity killer. I’ve seen developers start out to write their own form validation framework until I point out that there is already one built in to ASP.NET that does the job (It’s not perfect, but it’s better than the one I saw being written).
All of that time spent reinventing the wheel is wasted because someone else has already written that code for you. And in many cases, did a better job as it was their only focus. In such a situation, finding an existing library (now you see what's SRL for?) that gets the job done can provide a huge productivity boost. (of course you should ask for permission and credit your sources where necessary)
The caveat in this case is to be careful to avoid non-extensible and rigid 3rd party libraries, especially for very specialized requirements. You might a lot of time trying to fit a round peg in a square box.
Even when you must invent here, good developers tend to write less (but still readable) code that does more. For example, rather than build a state machine to parse out text from a big string, a good developer might use a regular expression (ok, some will say that a regex is not readable. Still more readable than hundreds of lines of text parsing code).
By writing less code that does more, and by writing maintainable code that has fewer bugs, a good developer takes pressure off of the QA staff, coworkers, and management, increasing productivity for everyone around. This is why numbers such as 28 times productivity are possible and might even seem low when you look at the big picture.