Skip to content
HomeVideosBooks
AllTopicsTrends
BlogsPodcasts
HistoryListsWatch laterLiked videosFollowing

The videos, books, blogs and podcasts Hacker News keeps recommending, all in one place.

VideosBooksBlogsPodcastsAboutPrivacySettings

Data from Hacker News, HackerTube, HackerBooks, HackerBlogs and Open Library. Credits · Not affiliated with Y Combinator.

HomeVideosBooksBlogsPodcasts
Ctrl K
    Cover of Estimating software costs

    Estimating software costs

    Capers Jones · 1998

    Other
    Open LibraryAmazon
    Stats for nerds
    1recommend
    2mentions
    2people
    2011–2025years
    50% recommend50% neutral

    Mentions per year

    20112013201520172019202120232025

    What Hacker News says

    1. doctorleffNov 2025
      I taught these issues several times in the graduate Software Engineering Course. Good resources are the Standish Report:

      https://www.csus.edu/indiv/v/velianitis/161/chaosreport.pdf

      Also, anything that T. Capers Jones wrote. The most comprehensive one of these books is this:

      Estimating Software Costs: Bringing Realism to Estimating Hardcover ISBN-13978-0071483001

      Many believe the official recognition of the crisis in developing software were the two NATO conferences in 1968 and 1969.

      See the Wikipedia article on the History of Software Engineering.

      There have been two small scale experimental comparisons of the waterfall formal model (requirements, design, code, test) and the more prototyping and agile method. They seem to have the same productivity in terms of lines per programmer-month but the formal method tends to produce larger software.

      thread
    2. blubApr 2011
      "that C is superior to full-blown C++[...]"

      I disagree that C is superior to C++ for most projects.

      First of all, C++ offers higher-level semantics which leads to an increase in productivity. According to [1], the ratio of C++ to C LOC is 1 to 1-2.5, but I'd be interested to read other studies or articles. My experience and [1] also contradicts your statement that rewriting code with STL/Boost will lead to increased code size. It's almost impossible for C++ to be more verbose than C - consider that you can write C-like code directly in C++.

      Second of all, for a developer that has good knowledge of both C and C++, writing quality C is harder. C is very prone to programmer errors, much more so than C++ where you can choose to use libraries/language features that completely eliminate some of these errors. e.g: scope-based destruction, the STL data structures, string classes, etc.

      Third of all, when discussing C++ many try to make C++ look as a frightening monster ("full-blown C++"?) where you have template meta-programming interacting with automatic conversions and operator overloading and all the other features in the worst possible way. This is not much different to claiming C is bad because you can use macros and void* for everything. The languages should be compared by real-world use patterns, not dreamed up criteria.

      [1] Estimating Software Costs (Jones 1998) and Software Cost Estimation with Cocomo II (Boehm 2000)

      "[...]that object-oriented programming is no panacea[...]"

      While it is true that some have argued for OOP as panacea, this is mostly a strawman. OOP is one possible solution that works most of the time.

      thread

    Related

    Cover of The economics of software quality
    2015–2025

    The economics of software quality

    Capers Jones
    4 recommend · 12
    Cover of Software Estimation
    2007–2026

    Software Estimation

    Steve McConnell
    58 recommend · 120
    Cover of Software engineering economics
    2013–2026

    Software engineering economics

    Barry W. Boehm
    2 recommend · 10
    Cover of Agile estimating and planning
    2011–2025

    Agile estimating and planning

    Mike Cohn
    5 recommend · 8
    Cover of Programming Productivity
    2012

    Programming Productivity

    Capers Jones
    0 recommend · 2
    Cover of Pro Git
    2009–2026

    Pro Git

    Scott Chacon
    142 recommend · 173
    Cover of Refactoring
    2007–2026

    Refactoring

    Martin Fowler
    94 recommend · 179
    Cover of Software tools
    2008–2026

    Software tools

    Brian W. Kernighan
    21 recommend · 44