Pro .NET Best Practices Book Review
I personally do not find software development an art form. It is not an unpredictable activity driven by crazy business users that come to work every day inventing a new way to operate their businesses just to savagely changing your requirements. Project teams that use changing requirements as an excuse for their dates constantly slipping and bugs being pushed to production are simply not good development teams and they are poorly managed. Even when you're in an environment where requirements are volatile, proper architecture and process engineering can level the playing field. One of the reasons for incompetent software development teams is what I like to call home brewed enterprises. A company that does not welcome external resources to the table when they are changing to meet the demands of today's hi-tech requirements for doing business will usually create a home brewed mess. The attitude that 'we have figured out how to run our business over the past 30 years and can figure out how to move forward on our own', is shortsighted and destine to fail. If your people are not continuously learning what the newest industry standards, best practices, programming language features, process engineering techniques, and management skills that have become available are, then you need to turn to outside consultants that are doing that to help you through changing times. One other thing, you have to actually take and execute their advice. I don't know how many times I have seen consultants brought in, asked for their opinion, only to have their advice ignored because the internal team did not have the skillset to execute their advice. If you don't have the skillsets available for building software right, you should not be building software, period. There is a much bigger gap between the professional software engineer and the average company software developer than most companies realize. They miss it because they have no one on their team that has experienced an actual software development project run right. Most company's IT departments are hitting about 10% of their potential. The reason the business doesn't know any better is because some improvement, no matter how little, is better than no improvement. The business simply believes the productivity gains they are getting for the half million dollar projects are what they have to pay. When in reality a shop that is practicing best practices could deliver five to ten times more functionality with a much higher quality for the same cost. Getting the message through to them after years of developing garbage is tough cookie to crack. That would mean a lot of people, from IT to the business, would actually have to say I was wrong. It would also mean that things would need to change, and home brewed enterprises hate change. The author of this book has done every software developer who does not want to be just another home brewer a great service. He has taken today's best practices from the .NET world and compiled them into one place. Granted a lot of the topics he covers will require further reading, but he has done a great job of introducing a ton of best practices along with the tools and resources you need to implement them. He does not just give you a bunch tools with an example, he also gives you sound advice on how to determine whether or not the tool or practice is right for your environment. This author has a very clear understanding of the fact that there are different teams with different skillsets in different environments and not every practice is right for every team. An example is his advice with agile processes, which is that you must have an open and trusting environment for agile to succeed. I have repeatedly seen agile process jammed down team's throats that couldn't handle it. They were not mature enough. They should have first been run with an experienced architect and project manager in place under the unified process in order to gain experience. The book starts out with a chapter that introduces several healthy concepts that should be understood about best practices in general. They include Practice Selection, Target Areas for Improvement, and Overall Improvement. The book continues with 12 more chapters. They include .NET Practice Areas, Achieving Desired Results, Quantifying Value, Strategy, .NET Rules and Regulations, Powerful C# Constructs, Automated Testing, Build Automation, Continuous Integration, Code Analysis, Test Frameworks, and Aversions and Biases. The book covers a ton of topics some of them include Technical Debt, Retrospective Analysis, Prospective Analysis, Application Lifecycle Management, Patterns and Guidance, Research and Development, Microsoft Security Development Lifecycle, Success Conditions, Documented Architecture, Improving Manageability, Increasing Quality Attributes, Personal Process, Commitment to Excellence, Coding Standards and Guidelines, Code Smells, Brownfield and Greenfield Applications, Boundary Analysis, Test Code Maintainability, Unit Testing, Automated Integration Testing, MSBuild Fundamentals, Automated Deployment, The CI Server, CI Lifecycle, Static and Dynamic Code Analysis, Mock Object Frameworks, Dunning-Kruger Effect, Ostrich Effect, Gambler's Fallacy, Ambiguity Effect, and Focusing Effect. The downloadable code is very well organized and usable. Each chapter includes a readme document that describes the code samples. The download also includes an Excel spreadsheet of the .NET Best Practices Scorecard that is found in Appendix B. Appendix A is a nice collection of all the resources used in the book including books, articles, guides and tutorials, and tools. My wife has accused me of going to work and speaking a foreign language and that is why no one understands what I am saying. The foreign language I have been use is called Best Practices and Industry Standards. It is a language that is constantly evolving. This book has the most current version of it as it relates to .NET. If I get my way, this book will be mandatory reading to be able to join my team. I suggest your team do the same. I highly recommend this book to any role involved with developing .NET software. | Pro .NET Best Practices |
0 Comments:
Post a Comment
<< Home