It’s an essential reference for any C# developer using concurrency in their applications. These days, hopefully that means most C# developers.
The 13 chapters provide short recipes for many uses of concurrency. The recipes are short. Therefore the recipes provide minimal breadth and depth on how each different recipe works. That’s great if you have a good understanding of how these different features, and you’re looking to decide which recipe is the best one for your current challenge. However, if you are looking for a tutorial or introduction to concurrency this book will leave you with many questions.
Stephen’s material is clear, concise, and will help you follow the proper guidance in a variety of situations. It will give you more options for concurrent programming, and you will be better at using them. If you know some of the concurrent techniques available to modern .NET developers, you’ll quickly catch on to the style and you’ll be exposed to recipes you may not know. That will make you a better developer.
This book is not for developers that have no experience with concurrent programming. Stephen assumes you know the basics. His explanations assume a background in the tools used.
This book has earned a handy place on my shelf. In particular, the chapter on Data Flows helps me remember to use this handy library more often. I believe I’ll reach the point where I reference this book whenever I’m looking at how to build a concurrency related library or program.
The subtitle of Mary and Tom Poppendieck’s latest book is “Ask the Right Questions”. This book guides you to a different Mindset, the Lean Mindset.
They begin by defining a Mindset as a mental model that enables us to make decisions. Throughout the book you are led by Anna and Otto, two characters that represent two modes of thinking. Otto is our everyday mind, where we make most of our decisions.He makes decisions on autopilot, adjusting quickly to any new situation. Otto uses his current mental models to guide his thoughts and actions. Anna is far more analytical. She analyzes the data behind everything and makes decisions slowly and in a measured fashion. She’s more likely to apply new models to new situations. Together, these two different ways of thinking provide a balanced view of the world and help us make great decisions. Throughout the book, they’ll show you how using both your current mental model, and questioning that model, you can improve yourself and your organization. One skill is learning to both modes of thinking appropriately.
The Poppendieck’s have again written a great book that will make you think about your organization, and how to make it better. It’s not a long book. It can be read over a weekend. but it will make you think, and think deeply.
The book is divided into 5 chapters.
The first, The Purpose of Business, discusses the Shareholder Value Theory, and Rational Economics. Then, they discuss alternative business theories, such as cooperative work systems. They stress the wisdom of centering your business around your customers. You must define your customers, your business, and the reason for your business’s existence.
The second, Energized Workers,explores techniques that can motivate and energize workers in your business.Poppendieck’s guide us through several case studies where organizations have created an environment where workers achieve beyond normal expectations. As you’ll learn, it takes empowerment and trust, among other things.
The third chapter, Delighted Customers, is a great read for anyone in an organization practicing Agile Development. Poppendieck’s talk about the risk of building just what is required, and never building features that truly delight customers. Again, case studies are provided from companies whose products delight you.
Chapter 4, Genuine Efficiency, talks about the tensions between productivity and flow efficiency. You’ll also learn the keys to energizing your team to build the right product, and to learn as quickly as possible what products and features are delighting customers, and which are not creating the reaction you want.
The final chapter, Breakthrough Innovation, provides a few case studies on companies that have made great innovative changes to their business and achieved great success. You’ll learn about a very successful news publisher, and how Intel moved from memory chips to CPUs.
This is not a cookbook filled with recipes you can just follow. In fact, Poppendiecks’ point out that the case studies in the first and 5th chapters follow opposing recommendations. What works for one company will not work for everyone. You must ask the right questions in order to find the right path for your organization.
Like all of the Poppendiecks’ books, I highly recommend this book. It provides many thoughtful questions that will help you make your organization more effective, following a lean mindset. If you want your organization to improve, you need to read this, and think about how it can help your organization.
You're finally ready for Library and API Design. This chapter provides guidance on how to create libraries and APIs that are easy to use correctly, and hard to mis-use. You know this is important if you've been developing software for any period of time. You've used well designed libraries, and you've used libraries that are hard to use. The guidance in this chapter will help you make sure that you are creating software that is intuitive for others to use.
I just finished reading "Visual Studio Team Foundation Server 2012: Adopting Agile Software Practices”, by Sam Guckenheimer & Nino Loje. (http://www.informit.com/store/visual-studio-team-foundation-server-2012-adopting-9780321864871)
Despite the title, the audience for this book should not be limited to teams that are using TFS as their main ALM tool. Most of the book discusses the practices for The Agile Consensus, not specific TFS features. The authors do spend some of the book discussing how TFS supports these practices. The core of the material is about the Agile Consensus, and how to help teams adopt it more effectively.
The first chapter defines the Agile Consensus and provides background and examples of Agile practices.
Chapters 2 - 8 define the Scrum process, and the support for that process in TFS. These chapters provide theory, practice, and how those practices are supported in Visual Studio 2012.
Chapter 9 is the most interesting. It discusses the process and the improvements made when Microsoft's Developer Division adopted Agile practices in 2005. It's an excellent case study for adopting agile in a large organization. In fact, this chapter alone makes the book worth buying.
The final chapter discusses processes for using agile across releases. How to manage continuous feedback, and drive future work.
There's a lot to learn here, whether you are using TFS or other agile toolsets. In fact, I think it's very useful if you use other tools: you'll learn to compare your tools with TFS. Maybe you'll see some practices you like, and make some modifications in your process. And that would be an agile improvement.
It’s a relatively short book, and it’s packed with good information. It’s worth the time investment.
I recently finished Jeremy Likness' book, Building Windows8 Apps with C# and XAML. This is an excellent first book for C# developers that want to explore Windows 8.
Jeremy's writing is clear, concise, and thorough. He provides an excellent explanation of the information and techniques he covers. The code is clear, and the examples are solid examples of common Windows 8 programming scenarios.
You can also download the associated code so that you can explore the apps, following along as he explains the techniques he uses to create the sample apps. The sample apps are small but complete programs that demonstrate the important techniques he covers.
You are new to Windows 8 development, but have a good understanding of C# and .NET.
This book gives a good overview of the new Windows 8 runtime, the new libraries, XAML capabilities in Windows 8, and the Windows 8 templates that ship with Visual Studio 2012. You'll also get an overview of MVVM, unit testing your Windows 8 apps, Live Tiles, Charms, and working with the store. You’ll learn the basics of XAML, and a few intermediate techniques as well.
Jeremy doesn't go extremely deep into those topics. That's the right decision for an introductory book. After you read this, you'll be ready to build Windows 8 store apps. You'll have the knowledge necessary to create professional apps that can be maintained and extended over time. By following Jeremy's advice, you'll leverage the functionality in the Visual Studio templates, and the Windows Runtime. You'll design your app in a way that supports extension and enhancement over time. Your code will also be positioned to take advantage of the upcoming features added in Windows 8.1.
If you want to get started building Windows 8 apps, get this book, and keep it handy. You'll turn to it often as you create your first few Windows 8 apps.
You have already released a few Windows 8 store apps and want a deeper understanding of Windows 8, the runtime, or XAML.
As I said above, Jeremy doesn't go extremely deep into any of the topics he covers. If you already know the basics, and some of the intermediate topics for Windows 8 development, you already know much of what Jeremy covers. Get this book for the junior members of your team, but you'll learn more from Jeremy's blog, and other detailed Windows 8 developer resources.
I don’t often review business books here, but “Good Strategy, Bad Strategy: The Difference and why it matters”, by Richard Rumelt is an exception.
For my audience, the best feature is that Rumelt is an engineer by training. He explains strategy from an engineering and scientific perspective. He begins his discussion by going over examples where a mission, or a set of buzz-word heavy press releases substitutes for strategy. From that moment on, you know this is not the normal business book. He picks apart such empty direction with the precision of an engineer, or a dilbert cartoon.
That first part of the book is a quick read, and quite humorous. Its value is in preparing you for the second and third parts of the book. That’s where the real value is.
The second section “Sources of Power”, describes where you can find leverage, or power, that enables a well-thought out strategy to succeed. You’ll learn to recognize drivers that can be part of a great strategy. Most of all, you’ll learn the elements of any successful strategy. On almost every page, I found something that I could apply immediately, and I’ve already found myself thinking through his examples and applying them to our current environment.
The final section “Thinking like a Strategist” provides insight into how to use your brain to evaluate strategies, and to create your own good strategies. In addition to learning to recognize a good strategy, you’ll learn how to create and execute good strategy. You’ll finally learn how to benchmark results of executing a strategy. Most importantly, you’ll gain insight into when and how to consider modifying, or even replacing a strategy that is not giving the results you hoped for.
It’s not often that I read a business book, and walk away thinking “I can use this immediately”. This book gave me that feeling several times. I was constantly finding new ideas, new techniques and tools to help me running our business. It’s well worth the read.
Over the holidays, I read “Driving Technical Change”, by Terrance Ryan. The subtitle providers a great abstract for the book: “Why People on Your Team Don’t Act on Good Ideas, and How to Convince Them They Should.” This book will give you tools and techniques that will help you get your technical recommendations adopted at your workplace.
Mr. Ryan divides the book into three main sections: Skeptic Patterns, Techniques, and Strategies.
In Skeptic Patterns, you’ll learn how to categorize the negative responses you receive to new ideas. This is the first technique you’ll need: Recognize why people resist your idea. You’ll meet “the uninformed”, “the burned”, “the time crunched”, and others, including my favorite, “the irrational”.
In Techniques, Mr. Ryan describes many techniques that you can use to drive acceptance of a new idea. In each case, Mr. Ryan cross references each technique with the kinds of skeptics that are most swayed by that technique. The good news is that you probably already know most of the techniques. Mr. Ryan helps the reader by motivating you to perform those actions, and which skeptics are most receptive.
Finally, in Strategies, Mr. Ryan proposes a plan that will, over time, move the greatest number of influential skeptics to your side of the argument.
He doesn’t promise that driving technical change will be easy. But, Mr. Ryan will arm you with techniques to succeed far more often than you probably do now. Even though I’ve followed much of his advice for many years as a consultant, I found myself thinking I need to keep this book handy whenever I want to get customers to change. It’s thoughtful, calm techniques will keep you focused on the end goal, and give you the techniques to get there. If you are responsible for driving change, or wish you could drive change, you need this book.
During my recent vacation, I read the final print version of Essential LINQ, by Charlie Calvert and Dinesh Kulkarni.
Normally, I try to answer the question, “Who should read this book?” That answer eluded me on this book, due to the thorough treatment Charlie and Dinesh give the subject. Essential LINQ is approachable by developers that have minimal experience with LINQ, and yet those developers that have been using LINQ since day one will learn something from this book.
Everyone will learn something from two chapters in this book. “The Essence of LINQ” describes the principles behind the LINQ libraries and language enhancements. By understanding the goals of LINQ, you’ll immediately gain insight that will make LINQ more approachable and more productive for you.
In chapter 16, toward the end of book, Charlie and Dinesh discuss some patterns you’ll run into while developing with LINQ. You’ll learn how to use LINQ to SQL entities as part of a large multi-tier application. You’ll learn how to improve performance in LINQ applications. You’ll learn how to separate concerns in LINQ based applicaitons. LINQ is too new to be considered complete in terms of ‘best practices’, and thankfully neither Charlie nor Dinesh approach this subject with that kind of arrogance. Instead, they offer their recommendations, and invite discussion on the subject.
Throughout the rest of the book, Charlie and Dinesh explain LINQ to Objects and LINQ to SQL from a usage standpoint, and from an internal design standpoint. In other chapters, LINQ to XML is discussed. The authors provide examples of transforming data between XML and relational storage models as well. In every section, they tie together those features with the concepts discussed in “The Essence of LINQ”. That continuity helps to reinforce your understanding of LINQ through its design concepts.
After reading this book, you’ll be able to leverage LINQ in all your regular coding tasks. You’ll have a much better understanding of how LINQ works, and when you’ll encounter subtle differences in how different LINQ providers may behave.
It seems you can’t discuss LINQ without at least wading into the controversy of LINQ to SQL vs. Entity Framework. This book wades there as well (It was finished about the time the first EF release was made). More time is spent on LINQ to SQL, as it is more approachable from an internal design perspective. However, the chapters that cover EF build on that knowledge to help you understand how the two database LINQ technologies are more complementary adversarial. In addition, they touch on when you should consider one over the other in your application.
This section is the least complete, but the most useful to look into the future of the LINQ universe. It’s too easy to view LINQ as LINQ to Objects, LINQ to SQL, and LINQ to XML, and nothing more. This chapter gives you a brief view some of the other providers people have created for other types of data stores. Looking at some of those providers (especially the IQToolkit) will give you a greater appreciation for how LINQ can be used with a wider variety of data sources than you ever imagined.
If you are interested in being more productive with LINQ, you should read this book. You’ll probably thumb through it again and again as you search for better ways to solve different problems.
I’m reviewing them together because I read both of them at the same time, and some of the content is inter-twined in my own mind.
Both books provide a wealth of practical advice on succeeding with an agile process. Throughout both books, the depth of Mike’s coaching experience comes through. With every element of advice, Mike includes a discussion about why each recommendation is what it is. He also includes a lot of “you may be thinking of …” comments with reasons why straying from his advice may cost you and hurt your project.
Throughout both books I found myself almost thinking Mike was inside my head, helping me improve. When an author does that, he’s clearly succeeding.
The two books are aimed at different, but overlapping audiences. Maybe because I’m in both audiences, I found both useful.
User Stories Applied goes into more depth about the process of creating user stories that will help drive your project to success. You’ll find advice that you should share with your customers. It will help them learn what makes a good user story, and how to express their needs and feature requests in the form of user stories. In addition, you and your team will gain a better understanding about creating stories that show value, are not too big, and aren’t too small to provide real value. You’ll learn how to break epics into measurable deliverables for your team. Those skills will help you succeed with agile. Software project success starts with getting good input from stakeholders and customers, regardless of which process you choose. Mike’s guidance in User Stories Applied will help your team, and your customers get this crucial part correct.
Agile Estimating and Planning provides advice from a different angle. This book explains agile techniques from all angles: release planning, iteration planning, daily planning, and modifications when reality differs from estimates (you know, like it always does). The best feature of this book is how Mike seems to anticipate counterarguments from those in any organization that would be opposed to adopting agile. He counters those arguments with clear logic and solid explanations about why following his advice will achieve better results. From different angles, you’ll find advice for developers, project leads, customers and customer proxies. Whichever role you find yourself in, read the entire book. Knowing how other team members should be approaching the process will help build a functioning team across processes.
The key theme running through this book is that agile plans must be constantly revisited, because reality changes constantly. Agile planning is not something you do at the beginning of a project, it’s a series of ongoing activities throughout the project. That point is stresses repeatedly, and it’s worth it.
If you are looking into agile, or you’ve tried an agile process and haven’t had the success you’d hoped for, you must read these books. It will help.
I don’t think Working With Legacy Code gets the respect and readership that it should. I believe that’s because most of us have a working definition of legacy code that implies something we want to avoid: We want to work on the cool new stuff, not the old legacy stuff. It makes us conjure images of C, or FORTRAN, or worse, COBOL. Or maybe something newer, but still mature enough you want to move on.
That’s not the definition Michael uses in his book. Michael defines legacy code as “Code without tests”. Based on that definition, do you work on legacy code? If you’re honest, you’ll say yes. Now, ask yourself if you want better techniques to work with code that doesn’t have tests.
If so, this is for you. You’ll learn several specific techniques that you can employ to take this code, make the absolute minimum number of modifications to get the code testable, and then you’ll feel safer applying your usual refactoring techniques.
I like the way the book is organized, with lengthy chapter titles that point to specific large scale code problems you’ll often find in code that doesn’t have tests. Example titles are “My Application has no Structure”, or “I can’t get this Class into a Test Harness”. Do those sound like problems you encounter? In these and other chapters, Michael identifies several common practices that lead to untestable code: dependencies on other system resources, unavailability of public interfaces to support testing, lack of interfaces for mocking, and so on. Each chapter title is more or less a description of the current problem, and the chapter content is a set of techniques that will enable you to move that code into a more testable design Once you can apply tests, you can add those tests and then go about your changes.
Other chapters show how to write tests that help you understand the current behavior. While this can seem silly, it does help ensure you don’t make a mistakes as you move the code forward.
Final, the last section of the code is a set of techniques that help break dependencies between different parts of a legacy system so that it is easier to inject those tests.
I haven’t said anything about the languages used in the book for examples. That’s because there are several: C++, Java, and C# all appear. One section that is specific to moving from procedural to OO techniques includes C. However, if you use a different language, don’t let that turn you off. The techniques are language agnostic, and that is proven by mixing the samples in different sections with different languages.
This is one of those books hat will always be handy,and will be one of the resources I turn to often when I inherit that set of code that just doesn’t have any tests. If you find yourself staring at blocks of undecipherable code, you should do the same.
I was recently notified that the 3rd edition of the C# Programming Language is out.
This version has is new in several ways. Obviously, it includes a description of all the new C# 3.0 language features.
In addition, a number of people were invited to provide annotations on the language specification. It’s an incredible group of smart people:
Brad Abrams and Krzystof Cwalina (of Framework Design Guidelines fame)
Joseph Albahari (of C# in a nutshell fame)
Don Box (of Don Box fame)
Jesse Liberty (of Programming C# fame)
Eric Lippert (member of the C# team, with a fantastic blog)
Fritz Onion (of Essential ASP.NET fame)
Vladimir Reshetnikov (SDET on the C# team)
Chris Sells (of Chris Sells fame)
Oh, and they let me add my annotations as well.
A while back, I read Mary and Tom Poppendieck's "Implementing Lean Software Development: From Concept to Cash". That tag line, "From Concept to Cash", is the thesis for the book: By minimizing the time between receiving a customer request and delivering value (for cash), a company can obtain a long term competitive advantage.
This book is primarily aimed at management (where the Poppendieck's first book was aimed at the development team). If your biggest challenge is convincing your management to go lean, give them this book. It contains a number of case studies, from the Boeing 777 program to the Polaris missile program to PatientKeeper (a mid-size software development company), to Open Source project. It uses those case studies to justify the claims that lean techniques will bring success.
Of course, as a developer, you may need to convince management that these techniques will pay off. If that's you, you should read this book. You'll be able to convince management why techniques like Test Driven Development, Continuous Integration, and Short Iterations will help the bottom line. That will get traction when a strictly technical argument won't.
A little more than a month ago, at CodeMash, I had the pleasure of spending quite a bit of time with Mary & Tom Poppendieck discussing software development, agile methods, the business value of software, and the general state of the industry. I came away very impressed by the breadth and depth of their knowledge, and their willingness to share it. Our organization can learn a lot from their strategy of software development. Dianne and I were impressed enough that we got a copy of each of their books. I started with Lean Software Development: An Agile Approach.
This is a fantastic book if you are trying to convince a resistant organization to go agile. Mary and Tom discuss 22 tools centered around 7 themes of software development agility. They show the business value of each of these tools. Sometimes it is shorter schedules, sometimes it is higher quality, still other times it is more profit for your business.
In every case, these tools give you the vocabulary, themes, and arguments to make to the business people. For example, when they discuss the tradeoffs between features and time, they build a profit and loss (P & L) model for the project. (Chapter 4) While developers may feel that a new feature request is a bad idea, and marketing may demand it because a major customer wants it, the P & L model will move that discussion forward: The added development time will mean a delay in getting to the market. That delay will mean lost sales. The model even predicts (and yes, I know predictions aren't 100% accurate) how much money will be lost by the delay. Now, the feature vs. time discussion can proceed in a logical manner. And, note that it's not an either / or discussion, if you're doing agile right. If you have delayed decisions to the last responsible moment (Chapter 3) you may find any number of lower priority feature requests that have not been started. These can be dropped in favor of the new requirement.
As a small software consulting company, I found the last item on agile contracts most interesting. Poppendieck's discuss how to build a mutually beneficial contract around shared goals for the customer and the vendor. Whichever line you sign, that discussion is worth reading: They found that a more agile framework supported by an agile contract would enable a supplier to be more profitable while holding down the costs for the customers. Building a contract with some uncertainty is always a challenge, but it's worth that perceived risk.
Lean Software Development is not a cookbook. You won't find directives saying you must have pair programming, standup meetings, test driven development (although all those may be part of a winning agile strategy). Instead, you'll find recommendations on seeing and elminating waste, providing feedback loops throughout your value stream (customers, business managers, developers, testers), making decisions at the last responsible moment, yet delivering interim releases as early and often as possible, and many others. Most importantly, as you try and convince your organization to adopt these methods, you'll find examples, case studies, and other evidence you'll need to convince your stakeholders to adopt these methods.
In closing, to recommend this book, let me just say that Dianne and I are buying copies for all our consultants, and for customers struggling with adopting a winning agile strategy.
I received a care package from Addison-Wesley the other day: My reviewer copy of the .NET Framework Standard Library Annotated Reference, Vol 2 (SLAR II).
This is a reference book, and as such, it is very dry reading. In fact, much of the text is verbatim from the ECMA standard for the pertinent portion of .NET framework library (in this case, Networking, Reflection, and XML processing). The real value in this book is in the annotations. There are many annotations on the classes, members, and namespaces documented here. These comments are everything from historical notes, reasons for inclusion (or exclusion of other possible features), design goals, and even the occasional apology where one of the framework designers felt they should have done better.
To close, I’ll quote myself from the inside cover: “The .NET Framework Standard Library Annotated Reference is the one reference you really need when you use the .NET Framework library. The annotations provide clear insight into the design choices that the library development team made when building the library. Those explanations will guide you to the best design choices for your own application code.”
Yes, I have been reading quite a bit.
This is a very good book for relative newcomers to .NET development. On the one hand, if you simply follow all the guidelines Francesco and Giuseppe present, you will be a very good.NET developer. The guidelines are an accurate representation of the accepted best practices for .NET development. There are over 700 tips and topics, so the topics do cover just about all the possible contingencies.
What is missing from this book is the justification for each topic: Why should you follow it, and what pitfalls await if you don’t? More importantly, without more justification for each recommendation, it’s hard to learn where the exceptions are or might be. And, there are almost always exceptions.
In the end, I would recommend this book to inexperienced .NET developers, or if you are looking for a set of guidelines to adopt in a corporate setting. With some annotations for the exceptions your group has, it’s a solid start. However, if you already an experienced .NET developer, this book won’t make you great.
All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.