What do you think?
Rate this book
The Problem with Software: Why Smart Engineers Write Bad Code
An industry insider explains why there is so much bad software—and why academia doesn't teach programmers what industry wants them to know.Why is software so prone to bugs? So vulnerable to viruses? Why are software products so often delayed, or even canceled? Is software development really hard, or are software developers just not that good at it? In The Problem with Software, Adam Barr examines the proliferation of bad software, explains what causes it, and offers some suggestions on how to improve the situation.
For one thing, Barr points out, academia doesn't teach programmers what they actually need to know to do their how to work in a team to create code that works reliably and can be maintained by somebody other than the original authors. As the size and complexity of commercial software have grown, the gap between academic computer science and industry has widened. It's an open secret that there is little engineering in software engineering, which continues to rely not on codified scientific knowledge but on intuition and experience.
Barr, who worked as a programmer for more than twenty years, describes how the industry has evolved, from the era of mainframes and Fortran to today's embrace of the cloud. He explains bugs and why software has so many of them, and why today's interconnected computers offer fertile ground for viruses and worms. The difference between good and bad software can be a single line of code, and Barr includes code to illustrate the consequences of seemingly inconsequential choices by programmers. Looking to the future, Barr writes that the best prospect for improving software engineering is the move to the cloud. When software is a service and not a product, companies will have more incentive to make it good rather than “good enough to ship."
For one thing, Barr points out, academia doesn't teach programmers what they actually need to know to do their how to work in a team to create code that works reliably and can be maintained by somebody other than the original authors. As the size and complexity of commercial software have grown, the gap between academic computer science and industry has widened. It's an open secret that there is little engineering in software engineering, which continues to rely not on codified scientific knowledge but on intuition and experience.
Barr, who worked as a programmer for more than twenty years, describes how the industry has evolved, from the era of mainframes and Fortran to today's embrace of the cloud. He explains bugs and why software has so many of them, and why today's interconnected computers offer fertile ground for viruses and worms. The difference between good and bad software can be a single line of code, and Barr includes code to illustrate the consequences of seemingly inconsequential choices by programmers. Looking to the future, Barr writes that the best prospect for improving software engineering is the move to the cloud. When software is a service and not a product, companies will have more incentive to make it good rather than “good enough to ship."
372 pages, Kindle Edition
Published October 23, 2018
56 people are currently reading
433 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 25 of 25 reviews
March 11, 2019
What a relief.
For some years I've been pursuing a notion about the problem with authoring software. I think that I can, to some degree, explain what the underlying problem is. After hearing a podcast interview with Adam Barr, I became concerned that he had reached the same conclusion that I have, but written a book about it before I got the chance to collect my findings.
In a sense he has, but not to a degree that will make any book of mine redundant.
This is, fortunately, not the book I was afraid it was going to be. What really concerned me was the subtitle, Why Smart Engineers Write Bad Code. To the degree we get an answer to that question, it's that it's because of lack of education. Barr's thesis is that the software development industry was well on its way to become a proper engineering discipline in the 1970s, but then, with the advent of personal or home computers, we got a generation of self-taught programmers that ignored all the published knowledge.
The book is mostly a historical review of what 'we' knew in the 1960s and 1970s, and how we got where we are today. It also makes a compelling case that we're about to lose yet another generation of self-taught programmers who will learn nothing of the past, but are, in the words of George Santayana, condemned to repeat it.
Barr never claims to hold a panacea for our troubles, but he does argue that if young programmers were taught the mistakes of the past, they might avoid them. I can't find fault with that line of reasoning.
There are, however, some lines of argument that start promising, but seem to get dropped before reaching the conclusion that I think one ought to draw. For example, the book clearly and lucidly explains how the programming language C is singularly vulnerable to a type of security breaches called buffer overruns. Since each generation repeats the mistakes of the previous generation, these types of security issues keep coming up.
When the book makes such a strong case against C as a programming language for network stacks, you'd expect that it'd then arrive at the logical conclusion that perhaps another language would be more appropriate. This never happens. When the book later touches on the topic of choice of programming language, it never rises over the usual no silver bullet platitudes.
As a historical review of the last fifty years of software development, the book gives a fine overview. I didn't learn much I didn't already know, but I'd imagine that for many readers, the material covered here would be the first time they hear about this. For a current programmer with a desire to learn about the industry's past, I recommend the book.
For some years I've been pursuing a notion about the problem with authoring software. I think that I can, to some degree, explain what the underlying problem is. After hearing a podcast interview with Adam Barr, I became concerned that he had reached the same conclusion that I have, but written a book about it before I got the chance to collect my findings.
In a sense he has, but not to a degree that will make any book of mine redundant.
This is, fortunately, not the book I was afraid it was going to be. What really concerned me was the subtitle, Why Smart Engineers Write Bad Code. To the degree we get an answer to that question, it's that it's because of lack of education. Barr's thesis is that the software development industry was well on its way to become a proper engineering discipline in the 1970s, but then, with the advent of personal or home computers, we got a generation of self-taught programmers that ignored all the published knowledge.
The book is mostly a historical review of what 'we' knew in the 1960s and 1970s, and how we got where we are today. It also makes a compelling case that we're about to lose yet another generation of self-taught programmers who will learn nothing of the past, but are, in the words of George Santayana, condemned to repeat it.
Barr never claims to hold a panacea for our troubles, but he does argue that if young programmers were taught the mistakes of the past, they might avoid them. I can't find fault with that line of reasoning.
There are, however, some lines of argument that start promising, but seem to get dropped before reaching the conclusion that I think one ought to draw. For example, the book clearly and lucidly explains how the programming language C is singularly vulnerable to a type of security breaches called buffer overruns. Since each generation repeats the mistakes of the previous generation, these types of security issues keep coming up.
When the book makes such a strong case against C as a programming language for network stacks, you'd expect that it'd then arrive at the logical conclusion that perhaps another language would be more appropriate. This never happens. When the book later touches on the topic of choice of programming language, it never rises over the usual no silver bullet platitudes.
As a historical review of the last fifty years of software development, the book gives a fine overview. I didn't learn much I didn't already know, but I'd imagine that for many readers, the material covered here would be the first time they hear about this. For a current programmer with a desire to learn about the industry's past, I recommend the book.
September 20, 2019
Die erste Hälfte ist ein Zwischending aus Autobiografie und Kulturgeschichte und sehr gut. Kritische Lektüre von Softwarebüchern und -theorien aus den 70ern und 80ern, Aufschlussreiches über die Nachteile und Folgen bestimmter Programmiersprachen, alles angenehm detailliert. Die zweite Hälfte ist dann allgemeiner und schwächer. Die Vorschläge ganz zum Schluss, was sich ändern müsste, fand ich wenig überzeugend.
January 28, 2019
Glad all the water in this book didn’t short-circuit my Kindle
August 14, 2021
I enjoyed this book as an anecdotal account of how the software engineering profession has developed over the past 4 decades. The structure of the book largely follows the progression of the industry’s repeated failed attempts to apply rigor to the field of software engineering. Barr provides a survey of a number of hurdles that the industry has overcome in recent decades such as the abolishment of GOTO programming and the subsequent transition to (ill-defined) “structured programming” a la higher level programming languages, the rapid takeover of OOP, the idea of unit testing, code reviews, agile methodologies, software architecture design processes, and several more key ideas that Barr thinks are the main areas the industry has improved.
Overall, Barr presents nothing novel, but rather highlights others’ contributions to the field, framing said contributions in the light of his experience riding the ever evolving software engineering (SWE) practice, progressing from a self-taught BASIC programmer, to Princeton CS student, to Microsoft Windows NT developer, ultimately arriving at a position in Microsoft in which he was dedicated to thinking about improving the SWE process for a more than a decade. The topics covered offer an intriguing insight into the attempts of a number of proponents to legitimize SWE as a true engineering discipline, but Barr does a good job of qualifying those attempts by highlighting the ways in which they consistently fell short and shedding light on the ways in which the SWE discipline still lacks a standard body of knowledge other engineering disciplines enjoy.
In several chapters, Barr introduces concepts like goto statements, OOP, interfaces, and other common design patterns, and expends considerable effort to explain these concepts to the laymen with prose and relevant code snippets. Barr’s goal is to elucidate how clearly these design patterns can improve software implementation, correctness, and maintainability. If the reader is a SWE like myself, these sections will fee redundant to some extent; However, I did find it enjoyable to read an experienced SWE’s approach to explaining the concepts to the layman audience. Additionally, Barr adds historical context to some of these design patterns, and thus the chapters containing these elaborations will still engage a broad audience to some extent.
In summary, I would recommend this book to anyone wanting to learn more about the collective SWE field as a whole, from historical anecdotes of programming in the 80s, to state of the art software design and implementation practices of today employed by a number of FAANG companies. For some reason, software engineering is still as hard as it was decades ago, but it’s largely changed in line with the information age it ushered in: early software engineering was performance focused resulting from a dearth of computing resources, whereas today’s software engineering is done in a context with immense computing resources and benefits more from complexity management. If you can accept the irony that this book never really gives a clear answer to exactly why smart engineers write bad code other than “because complexity management is hard, and here are all the types of complexity SWEs face”, then you will probably enjoy this book as a quick read that provides intriguing insight into the history and current state of software development practices employed in the modern tech industry. Somehow, software is still eating the world, apparently apathetic to how hard companies or SWEs they employ think it is to build it.
Overall, Barr presents nothing novel, but rather highlights others’ contributions to the field, framing said contributions in the light of his experience riding the ever evolving software engineering (SWE) practice, progressing from a self-taught BASIC programmer, to Princeton CS student, to Microsoft Windows NT developer, ultimately arriving at a position in Microsoft in which he was dedicated to thinking about improving the SWE process for a more than a decade. The topics covered offer an intriguing insight into the attempts of a number of proponents to legitimize SWE as a true engineering discipline, but Barr does a good job of qualifying those attempts by highlighting the ways in which they consistently fell short and shedding light on the ways in which the SWE discipline still lacks a standard body of knowledge other engineering disciplines enjoy.
In several chapters, Barr introduces concepts like goto statements, OOP, interfaces, and other common design patterns, and expends considerable effort to explain these concepts to the laymen with prose and relevant code snippets. Barr’s goal is to elucidate how clearly these design patterns can improve software implementation, correctness, and maintainability. If the reader is a SWE like myself, these sections will fee redundant to some extent; However, I did find it enjoyable to read an experienced SWE’s approach to explaining the concepts to the layman audience. Additionally, Barr adds historical context to some of these design patterns, and thus the chapters containing these elaborations will still engage a broad audience to some extent.
In summary, I would recommend this book to anyone wanting to learn more about the collective SWE field as a whole, from historical anecdotes of programming in the 80s, to state of the art software design and implementation practices of today employed by a number of FAANG companies. For some reason, software engineering is still as hard as it was decades ago, but it’s largely changed in line with the information age it ushered in: early software engineering was performance focused resulting from a dearth of computing resources, whereas today’s software engineering is done in a context with immense computing resources and benefits more from complexity management. If you can accept the irony that this book never really gives a clear answer to exactly why smart engineers write bad code other than “because complexity management is hard, and here are all the types of complexity SWEs face”, then you will probably enjoy this book as a quick read that provides intriguing insight into the history and current state of software development practices employed in the modern tech industry. Somehow, software is still eating the world, apparently apathetic to how hard companies or SWEs they employ think it is to build it.
January 30, 2019
A history of software-writing practices, with a focus on the challenges of achieving software correctness. Paints modern-day software engineering as a land of consultant-fuelled advocacy, devoid of empirical research and anything approaching real engineering practices.
February 16, 2019
The book can be a good intro to general obstacles in programming for project manager, especially if they have never programmed.
I really liked the promise that software engineering lacks any solid corpus of knowledge that’s shared by everyone in the profession. That most of developers are self-taught and that’s why it’s hard to agree on anything. But it didn’t actually go anywhere from here.
Then it just started go over all basic issue one would face early in theirs carrier. Gotos, Naming, memory management, oop, api, etc. it’s cool that those issues described in very simple language on a very basic level, so it’s accessible to anyone who doesn’t code. But if you are developer there is almost nothing in it, other than couple of observations and thick solid nostalgia for simpler times.
I really liked the promise that software engineering lacks any solid corpus of knowledge that’s shared by everyone in the profession. That most of developers are self-taught and that’s why it’s hard to agree on anything. But it didn’t actually go anywhere from here.
Then it just started go over all basic issue one would face early in theirs carrier. Gotos, Naming, memory management, oop, api, etc. it’s cool that those issues described in very simple language on a very basic level, so it’s accessible to anyone who doesn’t code. But if you are developer there is almost nothing in it, other than couple of observations and thick solid nostalgia for simpler times.
November 20, 2020
Thoughtful programmers often discuss "why is software terrible" and "why can't we be like the real engineers?" This is a thoughtful book-length answer, from a reasonably senior engineer with a wide breadth of experience.
I am not certain who the right audience is. The book makes some gestures at being accessible to non-programmers, but I suspect they would find parts of it heavy going. (E.g., the description of buffer overflows in C programs.) If you have a semester or two of programming, or some experience writing scripts and suchlike, you probably have enough background. On the other end, I have a PhD in computer science with a particular focus in software engineering and social aspects of programming -- so I am probably about as expert a reader as there is. I felt like a third of the book was review for me, another third was an interesting and useful presentation of stuff I half-understood, and another third was genuinely new insight.
The book opens with a biographical pattern, following the author as he moved from PC BASIC, to Princeton, to working for a software company, to Microsoft. The biographical structure is mostly a hook to give the author's perception of the development habits in these different communities and the problems they each produce. Old-style BASIC, for instance, inevitably degenerates into spaghetti code; C tends towards subtle string and memory problems, small software companies used to have a culture of "throw it over the fence once it compiles and seems to work for the dev", and Microsoft in the 1990s tended to emphasize trivial style rather than deep design in code reviews.
The second half of the book breaks from biography and is a series of focused studies of various topics. I thought this was the stronger part of the book. The author points out that we *do* know a number of things that would help -- systematic structured code-reviews with definite things to look at, better languages, better tools, formal methods, etc -- and we mostly just don't bother. A great deal was worked out in careful scientific studies in the 1970s by old-line hardware companies -- and then the microcomputer people assumed it didn't apply, were too small to do their own studies, and just forgot about it.
I wish the author dug a little deeper into the social dynamics here. Why are programmers so resistant to best practices? Why don't engineering managers and CTOs push? Yeah it's more fun to code than to write test plans, but debugging production failures is even worse, and probably we'd get used to the test plans. Is it that too many engineers started out self-taught? That academics don't bother to teach software engineering because school assignments are too small?
Even without a careful set of recommendations, there's a great deal of thought-provoking material here and I recommend the book highly. You could use this as a good course book in an undergraduate or masters-level software engineering course.
I am not certain who the right audience is. The book makes some gestures at being accessible to non-programmers, but I suspect they would find parts of it heavy going. (E.g., the description of buffer overflows in C programs.) If you have a semester or two of programming, or some experience writing scripts and suchlike, you probably have enough background. On the other end, I have a PhD in computer science with a particular focus in software engineering and social aspects of programming -- so I am probably about as expert a reader as there is. I felt like a third of the book was review for me, another third was an interesting and useful presentation of stuff I half-understood, and another third was genuinely new insight.
The book opens with a biographical pattern, following the author as he moved from PC BASIC, to Princeton, to working for a software company, to Microsoft. The biographical structure is mostly a hook to give the author's perception of the development habits in these different communities and the problems they each produce. Old-style BASIC, for instance, inevitably degenerates into spaghetti code; C tends towards subtle string and memory problems, small software companies used to have a culture of "throw it over the fence once it compiles and seems to work for the dev", and Microsoft in the 1990s tended to emphasize trivial style rather than deep design in code reviews.
The second half of the book breaks from biography and is a series of focused studies of various topics. I thought this was the stronger part of the book. The author points out that we *do* know a number of things that would help -- systematic structured code-reviews with definite things to look at, better languages, better tools, formal methods, etc -- and we mostly just don't bother. A great deal was worked out in careful scientific studies in the 1970s by old-line hardware companies -- and then the microcomputer people assumed it didn't apply, were too small to do their own studies, and just forgot about it.
I wish the author dug a little deeper into the social dynamics here. Why are programmers so resistant to best practices? Why don't engineering managers and CTOs push? Yeah it's more fun to code than to write test plans, but debugging production failures is even worse, and probably we'd get used to the test plans. Is it that too many engineers started out self-taught? That academics don't bother to teach software engineering because school assignments are too small?
Even without a careful set of recommendations, there's a great deal of thought-provoking material here and I recommend the book highly. You could use this as a good course book in an undergraduate or masters-level software engineering course.
June 18, 2019
A majority of the book is devoted towards the history of software and programming languages. I’m not too sure if it answers the question posed in the title very well, but there are definitely traces of it running throughout.
The answer seems to be that programming, being so easily available to learn, has led to many self-taught programmers, with their own style and experiences guiding their way in their code. The programming taught in schools also is not awfully specialised, not training how students will most likely be dealing with code after they graduate (maintenance on other people’s code), and there is no such rigour in the ‘engineering’ aspect, as compared to ‘proper’ engineering (e.g. civil engineering, electrical engineering), with no fixed or well known terminology or methods.
Probably an excessively crude summary.
Questions that I have, now:
How much depth is there to be found in methods and programming terminology? In programming algorithms, specifically, discounting specialist programmer roles like in security. Algorithms are probably used widely by any programmer, so how many good principles can we find and use and teach?
The answer seems to be that programming, being so easily available to learn, has led to many self-taught programmers, with their own style and experiences guiding their way in their code. The programming taught in schools also is not awfully specialised, not training how students will most likely be dealing with code after they graduate (maintenance on other people’s code), and there is no such rigour in the ‘engineering’ aspect, as compared to ‘proper’ engineering (e.g. civil engineering, electrical engineering), with no fixed or well known terminology or methods.
Probably an excessively crude summary.
Questions that I have, now:
How much depth is there to be found in methods and programming terminology? In programming algorithms, specifically, discounting specialist programmer roles like in security. Algorithms are probably used widely by any programmer, so how many good principles can we find and use and teach?
September 9, 2019
This was a powerful book which confirmed many of my suspicions about the industry. Software is written poorly, which is part of our general tech malaise. The industry's desire to be a formal engineering discipline, but distracted by the framework-of-the-day hype, has led it to repeatedly create worse and worse software. The attitude of "moving fast and breaking things" has led to software being more about infinite programmers with typewriters than good engineering and good design.
The quick uptick in venture capital and programmer salaries has meant that companies can afford to hire bad engineers, and people will apply for high-paying jobs even if they're poor engineers. Rewarding the ability to write code, no matter how bad, has resulted in a lot of bad code unsurprisingly.
There are definitely a few suggestions the author makes at the end. It would've been nice to see more suggestions, but it does get across the point that the author is just as stumped as everyone else. As an engineer, it's really up to us to dig ourselves out of the hole we created. I don't know that we're up to the task, but I'm afraid we're not.
The quick uptick in venture capital and programmer salaries has meant that companies can afford to hire bad engineers, and people will apply for high-paying jobs even if they're poor engineers. Rewarding the ability to write code, no matter how bad, has resulted in a lot of bad code unsurprisingly.
There are definitely a few suggestions the author makes at the end. It would've been nice to see more suggestions, but it does get across the point that the author is just as stumped as everyone else. As an engineer, it's really up to us to dig ourselves out of the hole we created. I don't know that we're up to the task, but I'm afraid we're not.
May 5, 2019
This book is an interesting, thought-provoking chronicle about the history of the software development profession.
Adam Barr does a very good job going through this history, taking his own career as a software developer at Microsoft to illustrate and put more emphasis on his message.
The reader will get interesting perspectives about:
- How making software differs from other more traditional professions from the engineering and/or research domains;
- How making software, despite having being made now for little more than 60 years, is still being a discipline mostly defined by individual knowledge and self-made education, other than being defined by standardization and the collective accumulation of knowledge and experience from its practitioners.
The book finishes with a group of things that, according to Barr, must be done if we really want to turn software development into a more formal, more able-to-measure and predictable profession.
Adam Barr does a very good job going through this history, taking his own career as a software developer at Microsoft to illustrate and put more emphasis on his message.
The reader will get interesting perspectives about:
- How making software differs from other more traditional professions from the engineering and/or research domains;
- How making software, despite having being made now for little more than 60 years, is still being a discipline mostly defined by individual knowledge and self-made education, other than being defined by standardization and the collective accumulation of knowledge and experience from its practitioners.
The book finishes with a group of things that, according to Barr, must be done if we really want to turn software development into a more formal, more able-to-measure and predictable profession.
April 5, 2019
As a software developer, this was a quick and enjoyable read for me. My experiences and opinions are pretty much the same as the author's. However, it wasn't what I expected: it was recommended by a developer, so I thought it was aimed at telling developers how they could improve their work. Instead, it assumes no experience with the profession, and offers little advice beyond a roundup of established methodologies. Therefore, I'm not sure who would benefit from the book: laypeople have no reason to care, developers who work to improve their skills would already know the material, and developers who don't care (unfortunately, the majority) won't read it.
September 11, 2019
I really enjoyed this book. It doesn't really provide any solutions to writing better code. Rather the author discusses his own experience learning to program and then working at Microsoft as a developer in the early 90s. I did enjoy the insights into why the author believes software engineers write bad code.
Most of it revolves around the fact the software engineering isn't really treated like a proper engineering discipline with peer reviewed methodologies and process that have been vetted by both the industry and academia.
Most of it revolves around the fact the software engineering isn't really treated like a proper engineering discipline with peer reviewed methodologies and process that have been vetted by both the industry and academia.
April 7, 2019
This books gives a history of software development practices and how they have changed overtime. The author makes an argument that academia and industry need to be more closely aligned.
This book doesn't mention CI/CD, static analysis tools and version control systems. I would add a chapter dedicated to these practices and explore how they have helped or not.
This book doesn't mention CI/CD, static analysis tools and version control systems. I would add a chapter dedicated to these practices and explore how they have helped or not.
May 18, 2019
A good intro for the challenges, history, and eras of software engineering with a hard emphasis on the lack of empirical studies to improve itself.
It also has a good list of references for early work in this domain and emphasizes that even if they are old, they are still very relevant since domain didn't advance much to apply engineering rigor.
It also has a good list of references for early work in this domain and emphasizes that even if they are old, they are still very relevant since domain didn't advance much to apply engineering rigor.
July 7, 2019
Valuable read
As an software enginer I enjoyed the book. Barr highlights several reasons that actually lead to accidential complexity. Since the industry is quite young there has not established good enough practices and procedures (including apprenticeship and teaching) that would meet the challenges in modern software engineering
As an software enginer I enjoyed the book. Barr highlights several reasons that actually lead to accidential complexity. Since the industry is quite young there has not established good enough practices and procedures (including apprenticeship and teaching) that would meet the challenges in modern software engineering
August 14, 2019
A decent review of the history of software development, but the narration was unorganized. I'm not convinced this book has sussed out the right answer to "why smart engineers write bad code". It's more like a bunch of possible answers, loosely strung together. The book does at least have many good references I'd like to follow up on, though.
August 13, 2020
Enjoyable read. Author summarises well problems he has encountered in software development, and makes sound suggestions on how to fix these. Read in the context of being a software developer, it’s particularly useful. But it’s a only a piece of the puzzle, not the definitive answer to your software teams woes.
October 21, 2024
One of the best books that I have ever read! Provides a nice review of the history of software development over the last four decades. Also, provides important advice to those who teach future software developers.
January 14, 2019
A recommended reading for any person related to Software Engineering.
May 13, 2019
This is a really good book that I wish every developer would be required to read.
May 8, 2020
Glad to be done with this book. A couple of opening chapters were entertaining and most points are easy to agree with, but man, does it get dry... A bit disappointing.
October 29, 2020
very interesting read although I still don't understand how licensing will make things better. some ideas are good but certification and licensing idea I did not like at all.
November 25, 2021
Feels like it’s just another opportunity for learned helplessness. Not much prescriptive or helpful. Some interesting history.
September 23, 2024
A good entertaining book with lots of good insights.
August 11, 2020
The software industry has a big problem - Nobody has figured out how to teach coding. University keeps churning out 'Software Engineers' or 'Computer Scientists', but they never actually learn what they need to know to be good programmers.
Most coders have learned by coding. However, most only work on small 'toy projects', and never have to struggle with legacy code - i.e. poorly documented forgotten code, which is what developers spend most of their time doing.
In some ways it can be seen as a sequel to 'The Mythical Man-Month', Fred Brook's classic book from 1975 about managing large software projects. It's depressing how little things have changed since then.
The book suffers from one big problem - The audience is poorly defined. In order to understand most of the points it's necessary to grasp some concepts from C, C++ and other languages. It tries to explain the fundamentals, but for someone who doesn't already know what a string is, some of the explanations will surely seem cryptic. And for people who live and breathe C it sometimes feels a bit patronising.
Most coders have learned by coding. However, most only work on small 'toy projects', and never have to struggle with legacy code - i.e. poorly documented forgotten code, which is what developers spend most of their time doing.
In some ways it can be seen as a sequel to 'The Mythical Man-Month', Fred Brook's classic book from 1975 about managing large software projects. It's depressing how little things have changed since then.
The book suffers from one big problem - The audience is poorly defined. In order to understand most of the points it's necessary to grasp some concepts from C, C++ and other languages. It tries to explain the fundamentals, but for someone who doesn't already know what a string is, some of the explanations will surely seem cryptic. And for people who live and breathe C it sometimes feels a bit patronising.
Displaying 1 - 25 of 25 reviews