Know what's causing application development waste so you can turn the tide. This is the book your Systems Integrator and your Application Software vendor don't want you to read. Enterprise IT (Information Technology) is a $3.8 trillion per year industry worldwide. Most of it is waste. We've grown used to projects costing tens of millions or even billions of dollars, and routinely running over budget and schedule many times over. These overages in both time and money are almost all wasted resources. However, the waste is hard to see, after being so marbled through all the products, processes, and guiding principles. That is what this book is about. We must see, understand, and agree about the problem before we can take coordinated action to address it. The trajectory of this book is as In Chapter 1, we explore how bad the current state is. The three industries that address software waste are discussed, including the legacy software industry, neo-legacy software industry, and legacy modernization industry. Examples of application waste are illustrated from both public and private sectors. In Chapter 2, we explore the economics of the software industry. Although the economic tradeoffs are changing at the speed of Moore's Law, our approaches are not keeping pace. Learn how information systems really behave in terms of actual application development. In Chapter 3 we use "root cause analysis" to reveal the real contributors to this situation, which are dependency, redundancy, complexity, and application centricity. Chapter 4 recounts the many failed attempts we've made in the past to deal with information system complexity, including relational databases, ERP systems, enterprise data modeling, service oriented architectures, and APIs, Agile, data warehouse and business intelligence, outsourcing and offshoring, cloud, Software as a Service (SaaS), data lakes, machine learning, and artificial intelligence. Chapter 5 dismantles seven fallacies that contribute to our remaining stuck. For example, the first fallacy is "We need detailed requirements or we won't get what we want." The quagmire is not affecting all sectors of the economy equally. Chapter 6 looks at how this is playing out in the government and private sectors, large and small companies, and various parts of the IT industry itself. Chapter 7 outlines some action you can take now to begin to extricate yourself, including a detailed assessment and defining metrics for measuring and preventing software development waste.
Full disclosure, I work for Semantic Arts and Dave McComb, so my review is from the perspective of someone who works with technology in this framework.
This book is great if you're looking at the long history of application development and system architecture in large agencies/firms with modern data problems. Most data problems are modern data problems, in that there's "too much" data and not enough way-finding metadata or search and retrieval mechanisms or trust. Dave has a finger on the pulse of the problem. He's got much experience doing consulting in IT and data architecture, so much of what he presents as evidence is anecdotal, but it's the wisdom of experience and there's truth to his assertions. If you're looking for exhaustive post-mortem analysis of specific technology situations or components or types of frameworks, you won't get that here.
I've been working with semantics for the better part of ten years and while I think it's easy to buy into "The Latest Craze" it's still almost insurmountably difficult to develop solid applications that are effective. What I like about Dave's approach is that he doesn't overcomplicate or over-commit to tech ideologies. He's still learning, staying connected to cutting edge semantic development and thought-leaders, and tuning his approach to data-centric solution development. He's resistant to the mechanisms that entrench organizations into over-commitment to solutions, preferring a light-handed approach to shifting the mindsets of leaders he works with. This book starts to outline Dave's methodology on approaching big, bad data.
This is a must-read book if you work in Enterprise Software, no matter if you’re a vendor or on the inside of the beast. Software architects need to read it too.
The history is fascinating as are the quagmires we inadvertently create for ourselves. I really cracked up in bemusement at how the rise of cloud and APIs, which are a huge step forward in so many ways, also promote more corporate complexity and silos because developers can so easily get a cloud instance to solve a problem and of course data is now hidden away in a new location. Hilarious and only “obvious” when you someone points it out.
This entire review has been hidden because of spoilers.
I hadn't heard of Dave McComb until about a week ago, when I read an article of his in the most recent issue of PwC's strategy+business. In both the article and the book, the author argues (as the subtitle would suggest) that application-centric approaches to enterprise software development projects are costing organizations collectively many billions of dollars and that entire industries (eg systems integration) are propped up and incentivized to keep it this way.
McComb traces the history of how we got here, provides anecdotal evidence throughout, and offers high-level approaches to address the problem. Along the way, he makes prognostications that will prove to test his hypotheses, and hints at a "companion book" that will dive into more detail on the solutions to the problem.
I'm off to buy the companion book, if it's available. After all, I intend to use my business to exploit the inefficiencies in the market. :-)
[I'm not a developer or data scientist, though I do work adjacent to them.]
We think about waste management as a physical endeavour with environmental impacts but rarely consider the enormous waste and redundancy inherent in the information industry. Its impacts are deep. It causes environmental, social, and economic harm, especially as we become increasingly reliant on technology to aid our working and living. The quality and usefulness of our digital tools has a daily impact on the way it *feels* to work and move through the world.
And currently, that's broadly not great.
This is a technical book - it outlines our relationship with, and broken expectations of, the software industry and how much dysfunction is built into it by design. Most of the world's data is locked into and duplicated across applications with questionable usefulness and useability, beholden to an opportunistic commercial culture that seems unable to keep itself away from grotesque bloating.
It's also very accessible for a technical book. I learned a lot. There were many examples in the book that connected with analogous social experiences in my work as a management and change consultant (I'm so sorry, mom). The patterns that prevail in the software industry are present across society.
As always, the best solutions use open standards (shared, transparent, accessible), connect complex information into living networks (avoid siloes), and provide semantic structure (meaningful context). Imagine if information could be surfed and surfaced in a way that felt helpful and efficient and didn't make you want to throw your laptop out of the window.
This is a good Big Picture Book but it has one important flaw, it equates SQL systems with relational systems. The author gives an example of SQL code that he calls elegant code.
The term elegant code always reminds me of why I have called myself for many years a language philistine. It is because I don't understand what people mean by elegant. Often it appears that what they mean is code that is terse in terms of keystrokes. The book doesn't explain whether this is what the author thinks or not.
The impression given here is that code is a program. But a program is more than code. Many people write code but few write programs. Coders apply solutions but programmers define problems. In this sense programming is the writing of ideas. What may appear elegant to coders doesn't necessarily represent efficient thought either for the writer or for the reader.
It is apparent that the author like all of the major database industry does not understand that SQL is not a relational language. The fundamental relational idea namely data independence has been unfulfilled for nearly 50 years now. It is a shame that the author does not appreciate its potential which would be a huge economic efficiency and advantage if such a system were ever understood and implemented.
Software Wasteland is another title that makes a strong case to get hold of your legacy systems. The difference is that it is more accessible than the previous book to people with a non-technical background. It is definitively one of the best explanations I have read on why IT systems have become so ridiculously complex in legacy organizations. The reasons are manifold. Companies buy large software suites with many modules they don’t need. Suppliers keep complexity high on purpose to safeguard future contracts. Prices with suppliers have been pegged decades ago. Mergers and Acquisitions boost the proliferation of different systems as does regional independence of the subsidiaries. This is a book CEOs should read just as well as tech experts as it powerfully illustrates the potential gains when legacy systems and unnecessary IT-complexity can be brought to heel.
I wanted to put this book down and just stop reading it after the first 20% of the book but the author actually has a lot of good points and ways to think about modern software design. Still, the author really has an ax to grind and that comes thru. I also have immediate distrust of anyone who uses "lean" and "software development" together in a positive way (if you are curious, please ask me why your MVP sucks).
He does correctly call out that CI/CD is a path to a new way of viewing software development. I'll even go a step further than the author: TDD combined with CI/CD and a strong devOps culture changes the game for software quality and development. However it still doesn't solve the scale, scope, and "monolithic micro services" issues that engulf the industry.
Good, succinct intro to the sheer waste that goes on in enterprise software development and procurement. I've started to read his related trilogy as well, I get the sense the writing could also do with some waste reduction and combine the four books into one, but the overall message is still worthy of reflection.
Excellent overview of the limitations of current software development paradigm: numerous applications each with their own (relational) database is inefficient. In his follow-up book he demonstrates how a data-centric approach can correct this: a common source of data for applications, organized as a semantic network (using knowledge graphs), is more efficient.
Nice overview. Identified 80% of the waste that you can reduce with 20% of the effort. Inspires you to look from a different angle. Also, some practical advice and steps are there albeit not easy to undertake.
Very important topic, and an interesting view on it. What makes me give only 3 stars is it is through large sections of it really sloppilly written. References are made without proper qualification and explanation, and vague and unclear language is often used. The first few chapters and the end are really read-worthy, but with tons of filler in the middle.