Construx

10x sounds nice which is probably why it stuck, but it came from actual research which found the difference was larger than 10x - but also they were measuring between best and worst, not best and average as it's used nowadays. https://www.construx.com/blog/productivity-variations-among-software-d…

> Can I replace 10 of my average engineers with this one person? The answer is never "yes". That’s because the “10x” is an order of magnitude difference between the best and the worst, not the average. https://www.construx.com/blog/productivity-variations-among-software-d…

It is depressing that people are happy to just throw anecdotal evidence around without even defining what metric they multiply by 10x or 100x. There is some literature on it. For example, this blog post [0] contains some references. I have only read Peopleware. It says 10x is the difference from worst to best in terms of time and number of defects across a few hundred programmers. Also interesting: Within the same organization, there was only a difference of 30%. This means the environment is much more important than the skill, experience, or personality of a programmer. I cannot find any studies after 2000. Most of the data is even older. The Peopleware data is from Cobol, Fortran, Pascal, and C. [0] https://www.construx.com/blog/productivity-variations-among-software-d…

The question reminds me of this classic chart from "Rapid Development," https://www.construx.com/uploadedImages/Construx/Construx_Content/Reso… It's a great reference for project management, but not very math heavy. More math-oriented I'd say: - "How to Measure Anything," although not specific to project management - "The Principles of Product Development Flow." Think of "product" in this context as anything you want made that is unique (not made made repetitively in a factory). E.g., software. There's some queueing theory in there. And although the math isn't always presented, you will get more out of it if you can figure out or understand the math behind the principles

Good article. Before beginning the Estimation process, it's best to talk with the prospective customer about Cone of Uncertainty first; it helps to set a proper context for later execution of the project: http://www.construx.com/Page.aspx?cid=1648

It creates a great path for employees to follow as well. You know exactly what you need to demonstrate to make it to the next level. Steve McConnell (or more accurately, I suppose, Construx) with the Professional Development Ladder (http://construx.com/Page.aspx?nid=244) was an early advocate for this idea, and Spolsky has discussed it a couple of times as well. Cash has limited motivational power, but it's akin to the physiological layer on the hierarchy of needs. If you're getting a shitty salary it's harder to give a damn about the success of the product or company. That being said, also brilliant is the idea mentioned to let people exchange one or more tiers of compensation for stock if they so chose.

I appreciate the overall point of the article, but have a gripe. The author (and others) gets it wrong on the original meaning of 10x. A 10x engineer isn't someone who is 10x as productive as their peers, they are 10x as productive as their worst performing peer. The original study the author links to compares the difference of work between the fastest code and the slowest code. The fast debugger and the slow debugger. When we talk about 10X, it should be about comparing it to the least productive team member - the 1X. There is always going to be a 1X person on the team. That's not bad if the team average is 1.5-2X, but if the average and discrepancy gets large enough, you're going to have the 10-100X team member who gets a lot done. Also, not all work is equal. The 10X engineer who is only 10X in programming may be a 1X in collaboration or documentation. That's not a good dynamic, either. Again, appreciate the point of the article, "build great teams", but we need the 10X person in each task to do that. If the build pipeline is slow and costing us money, I need the best people on the team to go figure that out. And, I need our worst engineer who is still learning to be involved so that they can grow their skills. Become a 1.1x, 1.2x, etc. Hat tip to these articles on 10x engineer studies: https://jasoncrawford.org/10x-engineers https://www.construx.com/blog/productivity-variations-among-software-d…

For some additional context on why the new list has fewer items. From the parent link: > Here are my nominations for software’s top 12 classic mistakes. Additionally: > To make the list of classic mistakes even more useful, in 2007 Construx consultants update the list of Classic Mistakes based on Construx’s work with hundreds of clients since 1996. The following mistakes were added: - Confusing estimates with targets - Excessive multi-tasking - Assuming global development has a negligible impact on total effort - Unclear project vision - Trusting the map more than the terrain - Outsourcing to reduce cost - Letting a team go dark (replaces the previous “lack of management controls”) These additions and changes produced a total of 42 classic mistakes. Construx then conducted a survey to determine how frequent and how serious these classic mistakes are. “Software Development’s Classic Mistakes 2008”. (PDF) https://www.construx.com/wp-content/uploads/2020/04/CxWhitePaper_Class…

One important thing to keep in mind about the "10x engineer" is that it is a largely manufactured concept that originates with Steve McConnell, the author of Code Complete. He read a study from the 1960s that showed productivity variations between programmers and concluded that there was a 10x productivity difference "between the best and worst engineer." Since popularizing the concept by naming his consulting company's blog "10x" (which he no longer does) he has had to defend this over and over again because there actually is only flimsy research (at best) to support the idea. For example, McConnell admits that the study he based the idea in "found no relationship between a programmer’s amount of experience and code quality or productivity." (See https://www.construx.com/blog/productivity-variations-among-software-d… The book "Leprechauns of Silicon Valley" (https://leanpub.com/leprechauns) further undermines the idea.

Is this list intended to imply that a so-called 10x programmer does not have these qualities? Or has the opposite qualities? Do 10x programmers kill puppies? In 40 years working as a programmer I have never heard a programmer call themselves “10x” except ironically, as a joke. The term seems to come from management, and maybe recruiters, as a shorthand for the obvious (and often large) differences in programmer productivity (according to multiple metrics) observed in both studies and in practice. Steve McConnell wrote a good article about it, you can find several others. https://www.construx.com/blog/the-origins-of-10x-how-valid-is-the-unde… Although no programmers go around calling themselves 10x or wearing an exclusive patch or tattoo this subject keeps coming up, as if the mere 1X programmers were oppressed and offended. In actual programming teams and projects everyone contributes in different ways, some people have more experience and skills than others, and we usually recognize the stars and the less-skilled. Programmer productivity is highly situational: I may work 10x faster than a colleague on project A, but change things up and I may be the junior on the team. Perpetuating this imaginary class system as if there’s a 10x caste pushing everyone else down, and consoling those who imagine oppression with feel-good lists like this can only cause more friction and resentment among programmers, when teams work best when everyone works together and helps…

It depends a LOT on what you're estimating. Estimating a CRUD line of business app is very much doable. On the other hand, estimating an innovative product using unproven tech or novel methods requires a proof of concept before even knowing feasibility. I worked with major consultancies, and the most serious gave you order-of-magnitude estimates, with iterating improvements on the estimation itself until you reached a +/- 15% estimation that was the best they could do. Very similar to: https://www.construx.com/software-thought-leadership/books/the-cone-of… In those cases, it was a very reasonable estimate because they'd done very similar things before. One of those consultancies used an tool and they had measured their teams' velocity and were very confident on their estimates. For one of my own projects, we had to estimate a rewrite of an existing app (with slight improvements), which is as easy as it can get in regards to estimation. We used several approaches, the one that ended up being closest to reality was Steve McConnell's tool Construx Estimate (no longer available but you can find a mirror here: https://web.archive.org/web/20170920093850/https://www.construx.com/Th… )

The original study was timing how fast developers could solve a given task. The slowest took 10x the time of the fastest. With this setup you can't really get negative results. And participants who didn't finish the task were excluded from the results. A summary of the research: https://www.construx.com/blog/productivity-variations-among-software-d… I don't think there is anything wrong with the math, it is just that real-world productivity is not as easy to measure. The study didn't measure the "maintainability" of the resulting solutions, only how fast they were completed.

A 10x developer is not ten times more productive than the average developer, they're 10x more productive than the worst developer. Wish this myth would stop perpetuating, they're very clear in the original study. Here's some more details from the horses mouth, Steve McConnell who popularized the concept in Code Complete: http://www.construx.com/10x_Software_Development/Origins_of_10X_%E2%80…

> How do you do this? I draw them the Cone of Uncertainty (http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertain…

I prefer this Steve McConnel's Professional ladder: http://www.construx.com/uploadedFiles/Construx/Construx_Content/Resour…

Yes, they do: http://www.construx.com/10x_Software_Development/Origins_of_10X_%E2%80… Eric's article is a prime example of what's wrong with software development writing: lots of opinion with a few anecdotes and analogies tossed in for good measure, but absolutely no reference to any scientific study to justify any of it. I'm not trying to pick on Eric, but it really bothers me the extent to which we listen to, discuss and ultimately adopt the unsourced opinions of our peers. How much of what we do is done simply because someone like Martin Fowler told us to? Why do we so seldom ask, Where's the evidence?

Steve McConnell makes some good points regarding 10x SW engineers in "10x Productivity Myths: Where’s the 10x Difference in Compensation?" http://www.construx.com/10x_Software_Development/10x_Productivity_Myth…

Steve McConnell himself doesn't dispute Bossavit's claims about the earlier studies (for the most part), he just disagrees about the significance of those claims. See McConnell's rebuttal in which he acknowledges the methodological weaknesses of the citations: http://www.construx.com/10x_Software_Development/Origins_of_10X_%E2%80… .

in the original experiment (sackman, erickson, and grant) they were able to successfully solve programming-contest-style problems in a tenth of the time that other people required. so maybe ten hours instead of 100 hours. this should not surprise anyone who's worked on a programming team or who has looked at code they wrote ten or twenty years previously. the actual ratios were from 5:1 to 28:1, but that was an understatement, because some of the programmers couldn't solve the problem at all in the allotted time. sackman, erickson, and grant suggested firing the 1× performers: > Validated techniques to detect and weed out these poor performers could result in vast savings in time, effort, and cost. https://www.construx.com/blog/the-origins-of-10x-how-valid-is-the-unde… https://dl.acm.org/doi/10.1145/362851.362858 complaints and issue lists were not evaluated, but rewriting twice a month would have resulted in not completing the tasks they were being evaluated on

Actually, it means a lot. It tells us how much we understand the project's timeline. Many projects get estimated way to early in the process, and the true level of uncertainty at that point is massive. If the low confidence level means the estimate has an upper end that isn't feasible, there are things we can do to increase confidence. Proof of Concepts/Spikes are explicitly for the purpose of taken an unknown feature and getting a better understanding of their complexity, scope, and timeline. (http://www.construx.com/Thought_Leadership/Books/The_Cone_of_Uncertain… So then the hard part is communicating to the business the current estimates and confidence level and that we can do some up front work to tighten down our estimate and the schedule. This is actually part of ACM's "Software Engineer Code of Ethics": "3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work and provide an uncertainty assessment of these estimates." As for pharmaceuticals, I have no experience there. I doubt that they really just let scientists go off and do whatever they want with unlimited budgets, and just live with the results.

Putting aside all the ad-hominem and everything-is-terrible, I think I learned a lot from following the references Tef makes in this talk. Some references (sorry for the formatting, if this becomes a thing I'll do the wiki and the logo): Slides: https://github.com/tef/emfcamp2012/raw/master/programming_is_terrible.… Blub Paradox: http://www.paulgraham.com/avg.html http://c2.com/cgi/wiki?BlubParadox Perl and 9/11: http://www.paulgraham.com/hijack.html 10x: http://hfs.sagepub.com/content/16/1/70.short http://www.construx.com/10x_Software_Development/Origins_of_10X_%E2%80… http://www.construx.com/10x_Software_Development/Productivity_Variatio… Waterfall (same pdf, linking from 2 sources): http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf http://leadinganswers.typepad.com/leading_answers/files/original_water… Conway's law: http://en.wikipedia.org/wiki/Conway%27s_law Unrelated, Pournelle's Iron Law of Bureaucracy (I just like this law): http://www.jerrypournelle.com/reports/jerryp/iron.html X-Y Problem: http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem Atwood, Don't Learn to Code: http://blog.codinghorror.com/please-dont-learn-to-code/ Wason selection…

Certainly, experience is a reasonable way to evaluate ideas, but that doesn't mean the evaluation is valid. I agree that the bloodletting example was meant to undercut the assertion. I also think the assertion - judging only on experience - is incorrect, and that the example is a valid one. We have many examples where experience lead to incorrect conclusions. By experience, Aristotle argued that things in motion come to rest. Everyone knew that ... until Galileo, further codified by Newton. One's experience can be wrong. Hence the reason for software usability research. See "Making Software", edited by Greg Wilson, for lay results of some of that research. Here's an example of a more direct, empirical study: http://neverworkintheory.org/2011/10/24/an-empirical-comparison-of-the… . You write "human beings rely on experience at all times to evaluate." We also use comparison testing, as with that paper link I gave you. A hope is to minimize preconceptions based on one's experience. We see this in the medical field all the time, where we find that even single blind testing can unduly affect the results. We also use prediction to evaluate. Einstein predicted a certain bending of light around the sun, which wasn't based on experience. Therefore, I place a weak meaning to "human beings rely on experience at all times to evaluate." We use it to guide our understanding, but also use other…

This is not scientific research, but many folks quote Joel's article on Smart, Get's Stuff Done. http://www.joelonsoftware.com/articles/fog0000000073.html Steve McConnell reported on the 10x phenomenon, but again it's not so rigorous that it could pass a Physics journal. http://www.construx.com/10x_Software_Development/Measuring_Productivit… Now venturing into the realm of survey design... If you were to ask 100 technical programming manager, and 100 banking vice presidents, "Would you be more likely to hire and promote your intern if they had 10 more IQ points, or put in 10 more hours per week" you would get a statistically significant different answer. This is based on a small sample size of personal observations across both industries. In finance and banking there gets to be a point where people are "smart enough". There is enough complexity in software that you can always extract more value from more intelligence.

Textbooks! Good textbooks strike a balance between coverage, depth and compression of reasonably current knowledge. They're not cheap brand new, so consider buying $current_ed-1. When I want to learn a topic, I literally buy a textbook and plow through it. Sometimes I'll buy a handbook or student's guide or pop. account of the subject to go alongside. I took an accounting unit at university. One of the smartest decisions I've ever made. I even crack the book from time to time to refresh my memory about something. Start with a financial accounting book intended for freshmen students in your country, and then management accounting (which is largely universal), and branch from there. A lot of accounting is actually about adjusting for imprecision; meanwhile, finance is about uncertainty. There's even a software-focused management accounting / finance book: Return on Software by Steve Tockey[1]. It's good. When you have the basics of this stuff, lots of business chatter becomes much more comprehensible. Your clients will appreciate that you speak their language and understand their pain points (cashflow is the biggest pain in any small business). [1] http://www.construx.com/Thought_Leadership/Books/Return_on_Software/

Well, if the author kindof hasn't seen it, I guess I should ignore this stuff: Boehm, Barry W., and Philip N. Papaccio. 1988. "Understanding and Controlling Software Costs." IEEE Transactions on Software Engineering SE-14, no. 10 (October): 1462-77. Boehm, Barry, 1981. Software Engineering Economics, Boston, Mass.: Addison Wesley, 1981. Boehm, Barry, et al, 2000. Software Cost Estimation with Cocomo II, Boston, Mass.: Addison Wesley, 2000. Boehm, Barry W., T. E. Gray, and T. Seewaldt. 1984. "Prototyping Versus Specifying: A Multiproject Experiment." IEEE Transactions on Software Engineering SE-10, no. 3 (May): 290-303. Also in Jones 1986b. Card, David N. 1987. "A Software Technology Evaluation Program." Information and Software Technology 29, no. 6 (July/August): 291-300. Curtis, Bill. 1981. "Substantiating Programmer Variability." Proceedings of the IEEE 69, no. 7: 846. Curtis, Bill, et al. 1986. "Software Psychology: The Need for an Interdisciplinary Program." Proceedings of the IEEE 74, no. 8: 1092-1106. DeMarco, Tom, and Timothy Lister. 1985. "Programmer Performance and the Effects of the Workplace." Proceedings of the 8th International Conference on Software Engineering. Washington, D.C.: IEEE Computer Society Press, 268-72. DeMarco, Tom and Timothy Lister, 1999. Peopleware: Productive Projects and Teams, 2d Ed. New York: Dorset House, 1999. Mills, Harlan D. 1983. Software Productivity. Boston, Mass.: Little, Brown. Sackman, H., W.J. Erikson, and E. E. Grant.…

Tom DeMarco, of Peopleware fame, wrote a book called "Controlling Software Projects: Management, Measurement, and Estimation". He has, in some ways, rejected his ideas in that book. In this article, "Software Engineering: An Idea Whose Time Has Come and Gone?" http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0… he states: "My early metrics book, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no." The tl;dr of his article is that the software projects that require tight cost control are the ones delivering little or no marginal value. That is, "To understand control’s real role, you need to distinguish between two drastically different kinds of projects: ■ Project A will eventually cost about a million dollars and produce value of around $1.1 million. ■ Project B will eventually cost about a million dollars and produce value of more than $50 million. What’s immediately apparent is that control is really important for Project A but almost not at all important for Project B. This leads us to the odd conclusion that strict control is something that…