Posted in , 2 November 2009
There are a lot of Windows books that touch on concurrency and they might be enough to get started. Concurrent Programming on Windows is different; it’s huge and should be thought of as an encyclopaedia of .net and Win32 concurrency.
If you’re a Windows developer involved in writing remotely demanding code then you should read this. It provides a coherent conceptual framework for how all the concurrency pieces go together. The samples while indicated as not production ready, are significantly faster and safer than easily available ones on the Internet or what your average developer will write.
The book does have some downsides. Given the comprehensive nature then you won’t need it all at any given time. It covers both Win32 and .net so developers that only deal with one of the other may want to skip sections. The focus is heavily on small examples so it won’t tell you all you’ll need when you scale up the techniques for applications but you will get building blocks.
Highly recommended for Windows developers. Most machines sold now are multi-core and we owe it to our users to learn to build the natural and useable experiences this hardware allows.
Joe Duffy’s weblog contains a lot of similar material.
“Recursive lock acquires are redundant and add unnecessary performance overhead. But worse, depending on recursion can make it
more dif?cult to understand the synchronization behavior of your
program, in particular at what boundaries invariants are supposed
to hold. Usually we’d like to say that the ?rst line after a lock acquisition represents an invariant “safe point” for an object, but as soon
as recursion is introduced this statement can no longer be made con?dently.”
Posted in team, 8 September 2009
A book on the people rather than technical aspects of software development. It’s told in mainly story form with a different author for each chapter and a few interviews. Some industries covered include games, defence, security, and music so it makes a varied collection.
I enjoyed the book but find it hard to point to anything specific to take away from it. It acts as examples of how particular people dealt with problems they faced working with other people. It does give a sense of hope by the examples that you can find a way to overcome awkward situations and people to work effectively.
“There’s nothing wrong with making a ton of money, but that’s not the type of thing that’s going to pull a team together to really achieve spectacular things. Yes, they’ll work hard because they think they’re going to make a ton of money, but I’m looking for people to beyond the productivity we get just from those types of motivations.”
Good light read which gives some insight into the softer side of delivering great systems.
Beautiful Teams announcement
Posted in software, 23 January 2009
This is a real craftsman type book for coding. It covers the vast number of design decisions that programmers make when building systems. I like the focus as failing to pay attention leads to bad names that torment the person having to perform maintenance later. There are plenty of examples to contrast good and bad code.
Given how specific the advice is, then it’s no surprise that I take issue with some of it. In a section called “Use Solution Domain Names” you are encouraged to use Computer Science terminology first and only resort to the problem domain if nothing springs to mind. I find that the improved communication with the Scientists from using their terms far outweighs easing talking to fellow software developers.
A particular emphasis I liked is the refactoring of real world code. It is hard taking over other people’s code but I try to see it as an opportunity. Too many programmers seem to adopt the attitude of write-once code. Certainly it can have value building from fresh to learn but so can pulling apart code and putting it back together better. It also allows you to improve the cleanliness of existing code without throwing the whole lot away!
It’s a good book with a back to basics attitude. The ordering and overall structure seems a bit erractic but I was happy with the snippet at a time. You will not agree with it all but there is a lot to learn about the construction of software one line, function, and class at a time.
Uncle Bob’s blog
Posted in software, 21 September 2008
A book focused on practical methods and tools on how to be agile. Each section of the book seems able to stand by itself. This is much like XP itself, which the book is based on. The value comes from the iteration between the practices which is not something emphasised.
It is split into a larger first section of clear and direct methods and the second which is more about the underlying values. Despite the defined nature of what it teaches then applying them may still be challenging for more forecast oriented organisations.
By making the sections fairly independent it makes it easier to read just what was relevant to what you are trying to implement. I do feel it lacked in flow between practices albeit by design. It also means that should you not buy into agile practices completely you can try out parts and see how well it fits your development style.
“Software development requires the cooperation of everyone on the team. Programmers are often called “developers,” but in reality everyone on the team is part of the development effort. When you share the work, customers identify the next requirements while programmers work on the current ones. Testers help the team figure out how to stop introducing bugs. Programmers spread the cost of technical infrastructure over the entire life of the project. Above all, everyone helps keep everything clean.”
A useful book if you want a practical explanation of XP practices, including guidance of challenges you may faces and limitations.
More details at The Art of Agile Development where some of the content is available online
Posted in software, 4 January 2008
Estimation of products and projects is process that is often done badly and for the wrong reasons. It tends to be used as a method to try to persuade or compel developers into doing the same but faster. This is a shame as more important activities of choosing between projects and options seem to get lost in the mess created.
Mike Cohn in the book frequently points out that a good plan can be used to make decisions with enough accuracy. If the project when carried out, takes more resources then the plan is at fault. If when estimating you fail to make slack for unexpected events, then it doesn’t mean that the people who carried it out are automatically lazy and incompetent for overruns.
The book is focused on planning in an agile environment, where frequent evidence-based plans are needed. It gives good coverage of the actions needed to ensure that users get higher value functionality quicker.
Particularly interesting I found was the discussion of the financial aspects of planning. Often in software and research areas the ones directly carrying out the work can become too removed from the monitory value of what they do. It goes to the extent of demonstrating calculating instruments such as the Net Present Value and Internal Rate of Return. This level of depth is welcome if unusual in book primarily about software development.
An agile estimating and planning process recognizes that our knowledge is always incomplete and requires that plans be revised as we learn. As a team learns more about the product they are building, new features are added to the release plan. As the team learns more about the technologies they are using or about how well they are working together, expectations about their rate of progress are adjusted. For a plan to remain useful, this new knowledge needs to be incorporated into the plan.
Excellent book, useful for learning to plan and estimate in an adaptive way.
More details of Agile Estimating and Planning at Mountain Goat Software
Posted in software, 22 October 2007
This book investigates the creative process of innovating technology and systems. It takes the approach of poking holes in mistaken ideas people have of the process. I’d have preferred the approach of writing more directly about what works but the writing is excellent and contains some insights useful to me.
The book is often amusing but it focused enough to be useful. It covers specific ideas such as the myth of having a single inventor behind an advance – the reality being that often there are others as creative or more so than the figurehead that history associates with particular innovations.
Discovering problems actually requires just as much creativity as discovering solutions. There are many ways to look at any problem, and realizing a problem is often the first step toward a creative solution. To paraphrase John Dewey, the inventor of the Dewey Decimal System, a properly defined problem is partially solved.
Scott Burkun
Posted in software, 1 July 2007
ClickOnce is a take on deploying rich client software in a safe isolated manner. It uses several disparate pieces of technology to achieve this and some of this leaks out. This book gave me sufficient guidance to get a system deploying to my taste using ClickOnce.
The sections on Code Access Security were particularly illuminating, better than books with larger sections that achieved less. The sufficient coverage in areas such as controlling the update mechanism and the automatic inclusion of dependencies was useful to me.
Unfortunately with a book focused on a technology the use is becoming marginalized. MSI technology is still needed many scenarios, albeit often due to badly written applications. On the other side there is Silverlight providing rich applications in a browser cross-platform. This is a shame as ClickOnce with a good application policy provides a better fit to user needs on Windows machines.
“ClickOnce makes it easy to get your smart client application into your users’ hands. From their perspective, all they have to do is click a link that you provide. From your perspective, all you have to do is drop some files on a deployment server and your application is accessible to end users. As developers, you are probably used to hearing statements like this only to discover that when you sit down and try to actually employ a technology that claims to be this easy, it never is. However, as developers, you will discover that if you use the built-in capabilities of ClickOnce, it really is this easy.”
Recommended if you need to deploy .net applications today over the Internet with the minimal fuss but I expect the ecosystem to change soon.
Brian Noyes’ weblog
Posted in software, 10 March 2007
Software adjusts to meet the needs of users. This process can leave remnants of the original design. The signs are most obvious if you work directly with the technology building solutions. Raymond’s book is a collection of stories of the thousands of design decisions made for Microsoft Windows and the quirks that result.
It can be hard to separate explaining decisions from advocating them. There is a good deal of detail about the unpleasant choices that were made. If you’ve programmed much against the Windows API then reading this book will be both a relief and frustration. Many Microsoft programmers go to great lengths to ensure compatibility, often in spite of software vendors.
THERE IS A constant struggle between people who write programs and the people who actually use them. For example, you often see questions such as, “How do I make my program so the user can’t kill it?”
Now, imagine if there were a way to do this. Ask yourself, “What would the world be like if this were possible?”
Great book for developers on Windows but don’t blame Raymond just because he is explaining or fixing some bugs.
Posted in science, 21 January 2007
This book is useful beyond the specific area of nanotechnology. Issues are covered in the areas spanning scientific research and the commercialisation of the it. It is useful for as it discusses the motivations and behaviours of entrepreneurs, researchers, engineers, and lawyers. This is done without overemphasising the roles while highlighting areas of contention; the need to balance collaboration in a university and holding secrets to make a business of them.
Latter the book covers some specific nanotechnology areas such as microelectronics, materials, and medical applications. The would be a useful introduction to a reader unfamiliar with the areas but a light read to a technologist working in the area.
It is nice to see a reprint of Feynman’s Infinitesimal Machines at the end of the book
Energy is the single most important challenge facing humanity today. As we peak in oil production and worry about how long natural gas will last, life must go on. Somehow we must find the basis for energy prosperity for the twenty-first century. We should assume that by the middle of this century we will need to at least double world energy production from its current level, with most of this coming from some clean, sustainable, carbon dioxide–free source. For worldwide peace and prosperity, it must be cheap.
An interesting field and nice to read a book presenting business and technology perspectives
Posted in software, 25 November 2006
This books attempts to introduce agile ideas to product development. At the same time it is trying to package agile principles for an enterprise environment. I see definite benefit for a project manager attempting to encourage a large product development company to adopt an evolutionary approach.
There is good coverage of giving teams responsible for new delivery the space the explore the problem. A large part of a project manager’s role is to protect the team from the external pressures so they can deliver on the needs. The counter-intuitive notion that reducing the daily push for progress gives better long term achievement.
A section on the needs of executives is insightful, that when performing novel development what is required is reliability not repeatability. You need to focus on the outputs of a process and allow the team members the authority to figure out how to provide this to you. This can range from the device or software itself to the supporting materials for a complete product delivery.
Confusion about reliable and repeatable has caused many organizations to pursue repeatable processes—very structured and precise—when exactly the opposite approach—mildly structured and flexible—works astonishingly better for new product and service development. If your goal is to deliver a product that meets a known and unchanging specification, then try a repeatable process. However, if your goal is to deliver a valuable product to a customer within some targeted boundaries, when change and deadlines are significant factors, then reliable processes work better.
Good but a bit too enterprise for my taste.
Jim Highsmith publications
Previous