fbpx

Three Secrets of Software Development

Individual skill makes a huge difference:

A good programmer is ten times more productive than an average programmer. A great programmer is 20-100 times more productive than the average. Studies since the 1960’s have consistently shown this. A bad programmer is not just unproductive—he will not only not get any work done, but create a lot of work and headaches for others to fix.

“A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates

Although most software is made by teams, it is not a democratic activity. Usually, just one person is responsible for the design, and the rest of the team fills in the details.

Only 10% of building software involves writing code:

Over the lifetime of the project, a programmer spends about 10-20% of his time writing code, and most programmers write about 10-12 lines of code per day that goes into the final product, regardless of their skill level. Good programmers spend much of the other 90% thinking, researching, and experimenting to find the best design. Bad programmers spend much of that 90% debugging code by making random changes and seeing if they work.

Programmers who spend much of their time writing code are too lazy, too ignorant, or too arrogant to find existing solutions to old problems. Great programmers are masters at recognizing and reusing common patterns. Good programmers are not afraid to refactor (rewrite) their code  to reach the ideal design. Bad programmers write code which lacks conceptual integrity, non-redundancy, hierarchy, and patterns, and so is very difficult to refactor.

Programming is hard work. It’s an intense mental activity. Good programmers think about their work 24/7. They write their most important code in the shower and in their dreams. Because the most important work is done away from a keyboard, software projects cannot be accelerated by spending more time in the office or adding more people to a project.

Software is hard, and obeys the law of entropy:

Software development obeys the laws of entropy, like any other process. Continuous changes leads to software rot, which erodes the conceptual integrity of the original design. Software rot is unavoidable, but projects without an effective conceptual focus can rot so so fast that they becomes worthless before they are even completed. Failure of conceptual integrity is probably the most common reason for software project failure. Such software become bloated, buggy, slow to run and slow to change, and and pleases no one by trying to please everyone. Software rot slows down progress exponentially, so many projects face exploding timelines and budgets before they are mercifully killed. Successful software does one thing only and does it well before trying anything else.

A 2004 study found that most software projects (51%) will fail in a critical aspect, and 15% will fail totally. This is an improvement since 1994, when 31% failed.

Subscribe on YouTube

Free the People publishes opinion-based articles from contributing writers. The opinions and ideas expressed do not always reflect the opinions and ideas that Free the People endorses. We believe in free speech, and in providing a platform for open dialog. Feel free to leave a comment!

David Veksler

Bitcoin advocate. Cypherpunk. Liberty maximalist. Enemy of fiat money, fiat food, fiat education. Founder of The Bitcoin Consultancy, Vellum Capital

View Full Bio

3 comments

Your email address will not be published. Required fields are marked *

  • Secrets and Wizadry indeed!!

    Re: “A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer.” –Bill Gates

    1. While reading the following articles, keep in mind that–instead of diabolically KILLING other human beings or UNILATERALLY ruining their reproductive genes, their lives and their futures–the money and effort COULD have been spent on many PRODUCTIVE, USEFUL things. Here is one of a few that come to my mind:

    Making MS Windows stable!! Hell, Gates cannot even keep computer viruses out of his own product. Why is he mucking around with real viruses?

    https://connect.liberty.me/bill-gates-genius-or-a-psychopath-you-decide-2/

    2. After looking at some of the (rather pathetic) hardware/software setup (see below) that Bitcoin miners are using,
    (see videos at
    https://www.youtube.com/watch?v=snr–K17bI0 <==Bitcoin Mining Room 1 of 2
    https://www.youtube.com/watch?v=wYHoE21kUcs <==Bitcoin Mining Rack 18 Video Cards 5.1gh
    and related youtube locations)

    I am disappointed that NOBODY in the Forth community seems to have addressed this issue using Charles Moore's GreenArray chips running Forth software. I would think that such a setup would DOMINATE the Bitcoin mining scene!

    Does anyone have news of such a project?

    http://dennisleewilson.com/simplemachinesforum/index.php?topic=673.msg1424#msg1424

    3. Sites and Blogs That I Consider Worth Exploring

    Forth
    Charles Moore: The Invention of Forth

    http://www.colorforth.com/HOPL.html

    ColorForth by Charles Moore
    http://www.colorforth.com/

    Forth Interest Group (FIG)
    http://www.forth.org/

    4. In an extemporaneous discussion I mentioned Bitcoin and Khan Academy as examples of the power of innovation and peaceful trade in the remnants of a division of labor society. (You can now use diaspora immediately, please see link below)!

    Back to the conversation I was having: In that regard, I related how “Progress by Incremental Improvement and Prototyping” (PIIP™) EXPLICITLY describes, encourages and drives INNOVATION as opposed to something one points to and talks about after the fact!

    https://connect.liberty.me/boundless/

  • “100 times more productive than the average” may be an exaggeration, but the first and third points are essentially correct.

    The second point is correct only if prototyping (“experimenting to find the best design”) doesn’t count as “writing code”. I would have included this experimentation in the “writing code” category, and much “design” work preceding this experimentation is wasted. Rapid prototyping, or agile development, is the most effective design process, but by agile development I don’t mean any process described by “agile development” consultants or academic software engineers or “agile development” software packages.

    Also, distinguishing “research time” from “coding time” is not straightforward. When I code, I research continuously. I don’t research one day and code the next. Questions arise routinely as I code, and I search for the answers as they arise. The blurring of this boundary is greater all the time and much greater than it was decades ago, before Google and stackoverflow.com.

    I’ll add a fourth point. Most software is only valuable to a few people who pay directly for its development. In other words, source code copyrights and similar IP are much less valuable in the software development business than most people realize.

    If you want most of the source code I write, I’m happy to give it to you, because a customer has already paid me for it, and no one else will ever pay me for the same or even very similar software. The code is practically useless to you except as a source of snippets or methods you might benefit by studying. The only advantage to me of not giving you the code is increasing the customer’s dependence upon me for maintenance, and the customer is usually entitled to the source code anyway.

    In other words, since most software development fits the service model, intellectual property in the software development business is worth much less than people commonly imagine. A customer might prefer that I not distribute source code for security reasons but not because I’m giving a competitor something for which customer had to pay me.

  • I agree with this article.

    Funny thing about being a great programmer (my observations of someone else – not me) is that you fundamentally cannot fit in. You threaten the mediocre ones with your massive but bug-free output, and you get in the way of the empire-building aspirations of the bosses. So, while you will be paid reasonably well as a subcontractor (being an employee would be madness), your reward will be 2x or 3x of an average programmer while your output is 100x. If you are lucky you may have a couple of friends at work, but you will be brought in when the projects are missing their deadlines and the pressure is on. They won’t let you throw away the mediocre code, you have to get the mess to work. There will be a lot of frustration in your work.

    Oh, well, that’s the way the cookie crumbles.

Featured Product

Join Us

Donate