This book was pretty helpful in clearing up some of my confusions about dependency injection frameworks.
I already was aware of the basics of constructThis book was pretty helpful in clearing up some of my confusions about dependency injection frameworks.
I already was aware of the basics of constructor injection, but was experiencing some pain around problems like constructor over-injection and lots of 1-1 mapping between interfaces and implementations. This book explores ways to fix these issues and many others.
Here are some topics the book covered that I really appreciated:
* DI patterns, including the different types of injection, and Ambient Context * DI antipatterns, including Service Locator * DI refactorings, including Abstract Factory and dealing with cyclic dependencies * Object composition, including implementing the composition root for common types of .NET applications * Interception
I particularly liked the way the Interception chapter went over Decorators and how to configure them, and then moved into how to implement and configure interception....more
Both McConnell and Fredrick referred to the book as helping describe why it's difficult to introduce change into a technology organisation.
Fredrick's summary was particularly useful, explaining that beyond people who get interested in change just for the sake of it or the visionary rewards they might foresee from it, probably a large part of a large organisation is only interested in a change if it either (1) will likely solve some problem that is causing the decision-makers of the organisation real pain or (2) is so widely adopted in the industry that the decision-makers fear if they don't adopt the change, they will be left behind.
So, that's the frame of reference from which I read this book—looking for ways to convince an organisation from the inside that it should adopt particular changes.
I think the book works on that level—it definitely covered the ground I wanted it to cover—but you need to frequently remind yourself to keep your interests in mind, because the terms the author uses are very focused on marketing to external clients.
Even keeping this in mind, some parts, such as the discussion of distribution channels, didn't transfer well at all, but were still very interesting, if not immediately useful to me, since I'm not a marketer, I'm a software developer. Plus, as a developer who has witnessed attempted "pioneer-to-settler" transitions, the last chapter about how the chasm affects not only marketing but the entire high-tech enterprise rang especially true....more
This book has a lot of good reviews on Amazon, as well as at least one good review here on Goodreads. And I think those reviews (well, most of them) aThis book has a lot of good reviews on Amazon, as well as at least one good review here on Goodreads. And I think those reviews (well, most of them) are fair. It's a good introduction to IT governance issues for its intended audience of "senior decision makers." Much of it probably would be an interesting read for the general public, too.
But I keep hoping someone will write something like The Jungle, but for the software industry—something to shock people into waking up and not just accepting crappy, buggy software any more. This book isn't it, and that's fine, it's obviously not meant to be. But I have to admit, that's the book I wanted to read, and this was the most-promising looking title I've been able to find so far.
This isn't the best book out there about Agile or Scrum. (I'm not sure which book is the best, but it's definitely not this one.)
If you're interestedThis isn't the best book out there about Agile or Scrum. (I'm not sure which book is the best, but it's definitely not this one.)
If you're interested less in how to apply Scrum and more in the authors' personal experiences in discovering Scrum and why they think it's a good idea, then this could be an okay book. If they had any experiences where Scrum didn't work spectacularly, though, those aren't included here.
It's particularly intriguing that in the Introduction chapter, when discussing introducing Scrum across several teams in a large organisation, Jeff Sutherland says, "While most teams were only able to meet the industry average in function points per month delivered, several teams moved into a hyper productive state producing deliverable functionality at 4-5 times the industry average." I'd really love to hear what the differences were between the average any hyper-productive teams--why Scrum worked so well for some but not others. But the answer is absolutely not in this book. This book is only about success.
Also, I agree with other reviewers about the poor editing--there are definitely places where things don't even make any sense at all....more
I can understand why many people sound as though they were disappointed with this book. It's not a "practical" book, like Code Complete, Rapid DevelopI can understand why many people sound as though they were disappointed with this book. It's not a "practical" book, like Code Complete, Rapid Development, or Software Estimation, that you can immediately put into practice and improve your software's code or schedules.
But whether or not you agree with McConnell's conclusions about how to "fix" software development by turning it into a profession, like engineering, medicine, or law, I think it does a good job highlighting some of the ongoing struggles in developing software and making you at least think about them.
I agree that some of the solutions McConnell advocates seem overly-regimented and out-of-touch with what is currently often promoted as best-practice, namely agile development.
I also understand why people might think the author seems to keep going on about best practices, but never getting to the "real content" of telling us what those best practices are. From some of his allusions to them, they seem to be those described in Part 3 of Rapid Development....more
Parts of this book are a bit dated, which is why I feel I should knock off a star, but it's still full of super-relevant insights about software develParts of this book are a bit dated, which is why I feel I should knock off a star, but it's still full of super-relevant insights about software development....more
I wanted a little bit more from this book, but it was still very interesting to get some ideas about how to sustain yourself through a career in softwI wanted a little bit more from this book, but it was still very interesting to get some ideas about how to sustain yourself through a career in software development, which can be difficult if you're more interested in mastering your craft than in climbing the corporate ladder, but find yourself working for employers that don't understand that career path.
I think it would be most useful though, not to people mid-career, but to new graduates or people in the first year or two of their career....more
I think there's a lot of food for thought in this book. Personally, I can remember reading Martin Fowler's Mocks Aren't Stubs some time ago and concluI think there's a lot of food for thought in this book. Personally, I can remember reading Martin Fowler's Mocks Aren't Stubs some time ago and concluding that I'd be a "classicist."
Some time later, I started working with mocks as a way to isolate unit tests from "slow" dependencies, such as databases, trying to make them run more quickly. I didn't have much success, though, because I was still writing my tests in a classicist style.
This book helped open my eyes to how the "mockist" style really works, and why it can be a good thing. I absolutely recommend it to any programmer who is doing TDD (or writing unit tests), but who still feels like when it comes to being a mockist, they just don't get it.
As a note on how to read the book, I got a bit bogged down in the middle section, with the worked example. I ended up skipping to the final section and came back to the middle after. Reading it like that worked just fine. I also think it could be interesting to alternate chapters of the middle section with those of the final section....more
The authors of this book come right out and state that it's meant to be an overview for people new to agile and lean software development. Since I'veThe authors of this book come right out and state that it's meant to be an overview for people new to agile and lean software development. Since I've already read a few books on the subject, I didn't find much new here. But to be fair, I was warned and probably should have paid heed.
If you've heard of agile or lean software development, but haven't read about it or tried any of its practices, and want an introduction, this book is probably a good one for you.
But if you've already read other books on agile or lean, you can probably skip it....more
This book gives a very detailed look at how to use agile to plan releases and iterations.
If you're looking for a general overview of agile, or you arThis book gives a very detailed look at how to use agile to plan releases and iterations.
If you're looking for a general overview of agile, or you are a developer who doesn't have to worry too much about release planning, this book might be a little overwhelming.
But if you're planning an agile project, and you need to know--or at least be aware--that there are options like feeding buffers and using the Kano model to help prioritize features, then this is the book for you....more
Interesting read, though since I want to apply lean to software development and not to manufacturing, I probably would have been better off sticking wInteresting read, though since I want to apply lean to software development and not to manufacturing, I probably would have been better off sticking with software-development books, even if they were about agile rather than specifically about lean....more
Even if you're not doing agile, this book has good ideas for how to help make your retrospectives better. I imagine I'll bump it up a star after I actEven if you're not doing agile, this book has good ideas for how to help make your retrospectives better. I imagine I'll bump it up a star after I actually start using the activities and can evaluate how effective they are....more
As I approached the end of this book, I was prepared to give it only two stars. I don't think it's a bad book, but it's a synthesis of ideas detailedAs I approached the end of this book, I was prepared to give it only two stars. I don't think it's a bad book, but it's a synthesis of ideas detailed more thoroughly in other books--which the author appropriately pointed out in each chapter--that I've mostly already read.
So, if you've already read the following books, you may want to have a look through this one before buying it to make sure it doesn't just repeat what you already know. On the other hand, if you haven't read some or any of the following books, beware that this book can't completely cover everything in them, and you may find yourself wanting more, and buying more books:
* Working Effectively With Legacy Code by Michael Feathers * Refactoring: Improving the Design of Existing Code by Martin Fowler * Head First Design Patterns by Freeman & Freeman, or Design Patterns Explained by Shalloway & Trott, or Design Patterns by Gamma et al * UML Distilled by Martin Fowler * Test-Driven Development: By Example by Kent Beck, or Test-Driven Development in Microsoft .NET by Newkirk & Vorontsov, or other TDD reading, including mock objects in testing * Extreme Programming Explained by Kent Beck, or other readings about agile programming practices * Refactoring to Patterns by Kerievsky
The thing that made me give it an extra star in the end was when I got to the appendix containing the descriptions of patterns. It contains good descriptions of how to test each pattern, including which classes you'll probably want to mock. If you're already familiar with mocking, you'd probably be able to figure out this information for yourself, but it's nice to have the information up front, gathered with the rest of the information for each pattern....more
This book set me straight on how Project works with resources, work, and duration. Now I know how to enter tasks so Project doesn't do auto-bizarro thThis book set me straight on how Project works with resources, work, and duration. Now I know how to enter tasks so Project doesn't do auto-bizarro things with them. And I know how to see baseline information....more
There were a few places where I laughed out loud, and a few where I exclaimed, "That's so true!"
But I found myself wanting more in-deMeh. It was okay.
There were a few places where I laughed out loud, and a few where I exclaimed, "That's so true!"
But I found myself wanting more in-depth analysis about how to fix it when I find myself in biting and humorous situations like these. And there are some recommendations that make sense. But I still found myself wanting more, not because I came to the book expecting the answers to all software development woes, but because some of the observations seemed so insightful that I just started expecting more follow-through.
I guess maybe it's just content better taken in small doses, and just for what it's worth. And I suppose that perfectly describes how I'd read a blog, which is apparently where the book comes from anyway.
Update: I'm bumping this up a couple stars. Since I first read this book a couple years ago, I find myself coming back to it for inspiration (or maybe it's really commiseration) when the organizational behaviour around me becomes exceptionally crazy.
In particular, I find myself returning to the "Information Starvation" chapter. Although some of that content is on the blog, I think it's presented more coherently in the book. Another chapter I return to frequently is the one on meetings, players, and agenda detection, which is also on the blog. And I find myself also visiting the content about performance reviews, No Surprises, which I think is only on the blog....more