The Leprechauns of Software Engineering review Ì 104

Summary The Leprechauns of Software Engineering

Of this telephone game are generally considered cornerstone The Leprechauns PDF or truths of the discipline to the point that their acceptance now seems to hinder further progressIn this short ebook we will take a look at some of those ground truths the claimed x variation in productivity between developers the software crisis the cost of change curve the cone of uncertainty and. This is one of those books that should have been a blog post or few The author argues some established facts in software engineering and the papers that spawned them I ll list them below The cone of uncertainty Uber programmers are 10 times productive than simpletons Waterfall doesn t suck it was invented to have something to compare with newer and better development life cycles The later you find a bug costly it is to fixThat s all I don t know if you have any strong feelings about these facts but apparently they are mostly based on some expert s gut feeling or problematic experiments The book mainly talks about the work the author had to do to uncover the truth It gets a bit predictable after the first time so I decided to skim a bit I was hoping for some counter examples later in the book so I could learn about what we can really measure scientifically in software development Unfortunately I found myself skimming to the end of the book and to make it worse it ended with a cliffhanger My disappointment was immeasurable and my day was ruinedPersonally I m guessing a seuel 10 years from now when we find out the Agile experts the community the author belongs to were selling us snake oil all the time and we totally ate it up Talk about foreshadowing

Read ´ PDF, DOC, TXT or eBook È Laurent Bossavit

The Leprechauns of Software Engineering

We'll hone our scholarship skills by looking up the original source for these ideas and taking a deep Leprechauns of Software PDFEPUB #182 dive in the history of their development We'll assess the real weight of the evidence behind these ideasAnd we'll confront the scary prospect of moving the state of the art forward in a discipline that has had the ground kicked from under it. TL DR Bassavit demonstrates that several widely cited claims about software engineering are not really rooted in convincing empirical evidenceI m impressed by the research and the clarity of thought He uite successfully takes down these leprechauns I think but as he admits he doesn t construct any sort of alternative epistemology He weakly suggests that we should raise our standards for empirical research and also maybe borrow techniues from the social sciencesI think Bassavit is a little bit too dismissive of anecdote and folk wisdom possessed by professional programmers He is right in condemning those who present eg the cost of defects is higher the later they are discovered as having the authority of empirical science behind it but that doesn t necessarily mean there is no other basis for software engineers to subscribe to this idea Economists for example are not afraid to posit generalizations about how the economy works based purely on mathematical models they think plausibly capture characteristics of real markets in situations where the empirical evidence is lacking or ambiguous or when the mechanism they are analyzing is suspected of being too non linearcomplicated for a statistical test to be plausibleIn fact they will often present their arguments using demand curves and production possibility frontiers generated from theory not from data that resemble in some ways the cone of confidence and upward sloping cost of defect discovery diagrams that Bassavit is so affronted byThe lesson I would take away from Bassavit s deconstruction is stop attributing any inherent authority to scholarly citations stop pattern matching on the scientific method as a substitute for critical reasoning devote less effort to the dubious project of imitating the methods of experimental science and effort to improving our mental models of software engineering by introspective not empirical means

Laurent Bossavit È 4 review

The software of Software ePUB #9734 profession has a problem widely recognized but which nobody seems willing to do anything about You can think of this problem as a variant of the well known telephone game where some trivial rumor is repeated from one person to the next until it has become distorted beyond recognition and blown up out of all proportionUnfortunately the objects. Software engineering tries hard to be a real science In the last four decades some claims have gained general acceptance 10x developers exist and defects become costly to fix the later they re discovered These claims are often followed by a list of imposing citationsIn The Leprechauns of Software Engineering Laurent Bossavit chases down the sources of these accepted facts and in the process demonstrates that there s no science behind themWhile he explains in detail how he manages to unravel the various citations in order to get to the heart of the matter the book is easy to read At times it s like reading a thriller I was literally turning pages and didn t want to put the book downThere s a risk that I suffer from confirmation bias but this could be one of the decade s most important books about software developmentMy only problem with the book is that I feel that I should not take citations for granted Instead in its spirit I should get to the original sources in order to verify that the author hasn t misrepresented them It s just that if we are to believe Laurent Bossavit that s a major undertaking For now then I ll choose to believe himI strongly recommend this book for all with an interest in software development


10 thoughts on “The Leprechauns of Software Engineering

  1. says:

    'Software engineering' tries hard to be a 'real science' In the last four decades some claims have gained general acceptance 10x developers exist and defects become costly to fix the later they're discovered These claims are often followed by a list of imposing citationsIn The Leprechauns of Software Engineering Laurent Bossavit chases down the sources of these accepted 'facts' and in the process demonstrates

  2. says:

    This is a confusing and ultimately uite frustrating book The basic premise is good the software development field is full of received wisdom that has mutated over time from simple reasonable hypotheses to being treated as established fact su

  3. says:

    This book debunks many myths in software engineers it's a great read and challenges what we know about our industry I recommended this to a friend of back and he said Nobody should write anything about software engineering without

  4. says:

    This is one of those books that should have been a blog post or few The author argues some “established facts” in software engineering and the papers that spawned them I’ll list them below The cone of uncertainty Uber programmers are 10 times productive than simpletons Waterfall doesn’t suck it was invented to have somethi

  5. says:

    Are you in IT? If so you must read this book There're a plenty of fallacies circulating which are based on unverified statements This book busts most popular but which is important it teaches an industry newcomer or even a seasoned professional to doubt bold sayings and ask right uestions to figure out what forms the foundation o

  6. says:

    Well researched debunking of some of the most stubborn myths in software engineering combined with a thorough case for critical thinking in software engineering For some reason I was constantly reminded of Facts a

  7. says:

    A brilliant book While the presentation could use some touching up the contents are well worth the modest Leanpub price This should be mandatory reading to anyone who has even a passing interest in software development methods

  8. says:

    TL;DR Bassavit demonstrates that several widely cited claims about software engineering are not really rooted in convincing empirical evidenceI'm impressed by the research and the clarity of thought He uite successfully takes down these leprechauns I think but as he admits he doesn't construct any sort of alternative epistemology He weakly suggests that we should raise our standards for empirical research and also maybe borrow

  9. says:

    pretty much what I got from this is that you can't trust a lot of meme rules of thumb in software engineering the

  10. says:

    If you've ever felt like there is something fundamentally wrong with the way software is developed in a projectenterprise environment then this book is for you The author shows you how a few cornerstones of the s