Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 1005. (Read 4670673 times)

=== Disadvantages ===
# Lack of Accountability: Lines of code measure suffers from some fundamental problems. Some think it isn't useful to measure the productivity of a project using only results from the coding phase, which usually accounts for only 30% to 35% of the overall effort.
# Lack of Cohesion with Functionality: Though experiments have repeatedly confirmed that while effort is highly correlated with LOC, functionality is less well correlated with LOC. That is, skilled developers may be able to develop the same functionality with far less code, so one program with less LOC may exhibit more functionality than another similar program. In particular, LOC is a poor productivity measure of individuals, because a developer who develops only a few lines may still be more productive than a developer creating more lines of code - even more: some good refactoring like "extract method" to get rid of [[redundant code]] and keep it clean will mostly reduce the lines of code.
# Adverse Impact on Estimation: Because of the fact presented under point #1, estimates based on lines of code can adversely go wrong, in all possibility.
# Developer’s Experience: Implementation of a specific logic differs based on the level of experience of the developer. Hence, number of lines of code differs from person to person. An experienced developer may implement certain functionality in fewer lines of code than another developer of relatively less experience does, though they use the same language.
# Difference in Languages: Consider two applications that provide the same functionality (screens, reports, databases). One of the applications is written in C++ and the other application written in a language like COBOL. The number of function points would be exactly the same, but aspects of the application would be different. The lines of code needed to develop the application would certainly not be the same. As a consequence, the amount of effort required to develop the application would be different (hours per function point). Unlike Lines of Code, the number of Function Points will remain constant.
# Advent of [[Graphical user interface|GUI]] Tools: With the advent of GUI-based programming languages and tools such as [[Visual Basic]], programmers can write relatively little code and achieve high levels of functionality. For example, instead of writing a program to create a window and draw a button, a user with a GUI tool can use drag-and-drop and other mouse operations to place components on a workspace. Code that is automatically generated by a GUI tool is not usually taken into consideration when using LOC methods of measurement. This results in variation between languages; the same task that can be done in a single line of code (or no code at all) in one language may require several lines of code in another.
# Problems with Multiple Languages: In today’s software scenario, software is often developed in more than one language. Very often, a number of languages are employed depending on the complexity and requirements. Tracking and reporting of productivity and defect rates poses a serious problem in this case since defects cannot be attributed to a particular language subsequent to integration of the system. Function Point stands out to be the best measure of size in this case.
# Lack of Counting Standards: There is no standard definition of what a line of code is. Do comments count? Are data declarations included? What happens if a statement extends over several lines? – These are the questions that often arise. Though organizations like SEI and IEEE have published some guidelines in an attempt to standardize counting, it is difficult to put these into practice especially in the face of newer and newer languages being introduced every year.
# Psychology: A programmer whose productivity is being measured in lines of code will have an incentive to write unnecessarily verbose code. The more management is focusing on lines of code, the more incentive the programmer has to expand his code with unneeded complexity. This is undesirable since increased complexity can lead to increased cost of maintenance and increased effort required for bug fixing.

EDIT: regarding 1.25 lines/hour, aminorex says 20 lines/day so that would be a bit higher, but a lot does indeed depend on the nature of the work. There is a some decent research that breaks down programming productivity into a variety of factors and things like quality (within which I would include commenting or lack thereof) and familiarity with the existing code are certainly significant. Also, anything that involves working on an existing system that you can't break/redesign at will becomes much harder (another factor).

That figure specifically excludes inherited code. If you read the blog post it's from we go into great detail to explain how we excluded libraries, license changes, and all other irrelevant changes from the count.

I live in Germany, good coders here earn 4000 Euro / month. So your $200.000 get 3,7 coders / year (not 10!!!).

Yea, it really depends on the country and type of work being done. In the USA, expert coders can earn upwards of $100 an hour.

Even the new forum software for bitcointalk.org is costing over 1million USD.

I live in Germany, good coders here earn 4000 Euro / month. So your $200.000 get 3,7 coders / year (not 10!!!).

And everybody doing Crypto Currency-development or who is intelligent & skilled enough to do so, would be considered a "good coder". Last but not least, you compete with >1000 Bitcoin startups in Europe, USA and Asia for the few skilled people, who can really develope a Crypto Currency.

Yea, it really depends on the country and type of work being done. In the USA, expert coders can earn upwards of $100 an hour.

But even a new feature is not something static and, it too, requires maintenance and further work or re-implementation. DarkSend operation, or Masternode operation, has been radically altered and tweaked a lot. DarkSend must have been rewritten as to the way it works at least 3-4 times since Feb '14, to the point that it's no longer DarkSend but rather a ...premix of coins that are sent normally. And it continues to evolve (blinding).

We had the same discussion a few days earlier on the 200k USD payment processor and I asked what am I missing... I saw the answers but I still couldn't get my mind to accept them. I finally concluded that in my part of the world, these numbers are simply astronomical for coders while in other parts they may be considered "normal". With 200k USD you'd probably hire at least 10 full-time coders for a year around here.

I think you're confused about the effort of implementing a particular feature vs reworking/improving a large number of things across an entire system. For example, darksend is around 2000 lines of code (didn't bother to strip out blank lines and comments which aren't normally counted), which makes it roughly 10% of the above numbers. https://github.com/darkcoin/darkcoin/blob/master/src/darksend.cpp

This is not meant to denigrate the amount of work on darkcoin/dash, as there has been a lot done on that coin besides just darksend, and lines of code is a rough measure anyway, but you can't say that "build their own anonymity systems from scratch" is necessary more work than, say, bandwidth controls on the p2p (without looking I would guess those commits were of similar size, and more work involved with reverse engineering).

It's true I haven't done much coding since mid-90s or something... I played around a bit with mining software and stuff around '13-'14 for scrypt and x11, but other than that, no. Anyway 1.25 lines of code per hour seems totally absurd even with inherited code. After all, there are coins out there that build their anonymity systems from scratch. Their programming work should be valued in the tens of millions per this type of accounting

A huge part of the purpose of Bitcoin is to prevent things from happening, things like double-spending, inflation, stealing coins, etc. Additionally, it must prevent those things from happening in the face of active attack.

For instance, in regular distributed systems engineering you can assume modulo failures the components of the system act in predefined ways; when those components do fail the failures happen randomly. I can easily shard a database for a bank across ten servers, and handle validation of the data by random spot-checking to get a sufficiently certain probability of detecting a failure. But Bitcoin is decentralized systems engineering, where security matters. If I'm running one of those shards holding part of the blockchain, I can't assume the others running other parts of the blockchain are honest - it can easily be in their incentive to be dishonest and deliberately not follow the protocol I'm expecting them too. I can't just test my way to ensuring the system works with high probability; I have to imagine how an attacker would attack it.

An analogy: imagine someone told you they had extensively tested a new cryptographic signature implementation by creating running billions of automatically generated unittests, all of which passed. Is this enough to know it works? Hell no! The attacker can do the math to find the one-in-a-trillion-trillion-trillion case that causes your code to fail, something that would simply never happen due to a random failure.

I'm not sure if you were referring to AlexGR but I don't think he's really a troll, just expressing an opposing point of view, which i certainly welcome. No need for an echo chamber of cheerleaders.

There are certainly people who post useless snarky comments, blatantly hostile attacks, etc. but he's not doing that.

^This user DASH troll is currently ignored.

It's true I haven't done much coding since mid-90s or something... I played around a bit with mining software and stuff around '13-'14 for scrypt and x11, but other than that, no. Anyway 1.25 lines of code per hour seems totally absurd even with inherited code. After all, there are coins out there that build their anonymity systems from scratch. Their programming work should be valued in the tens of millions per this type of accounting

IIRC devs generally cost about 600/diem, and produce about 20 lines in a day over the long-run.

You obviously know nothing about programming. Especially when it pertains to inherited and uncommented code.

Just 1.25 lines of code per hour of work? Isn't that exceptionally slow?

Combining the two together, there were 22 927 lines of code over the first 8 months, which is 18 342 hours of work, so $1 375 620 worth of effort."