The Scrum Field Guide: Practical Advice for Your First Year Book Review

This is one cool book. If you are starting to use Scrum, read it. If you are using Scrum, read it. If you are just wondering what Scrum is all about, read it. It gives the best insight into the workings of Scrum I have seen in a book. The chapters are laid out in a really nice to read format. Each one contains sections titled The Story, The Model (or The Practices in some chapters), Keys to Success, References, and sometimes Works Consulted (although I never figured out what the difference between these and references where?). The story is literally a story that comes from the author's field experience that introduces the topic the chapter covers and brings to light problems being solved by the next section, The Model. The Model and the Practices sections are the guidance and suggestions to help with the problems identified in the story. Keys to Success provide advice on how to execute the model. The book starts with an introductory chapter, Scrum: Simple, Not Easy, in which the author makes some very important points. I don't know how many times I have repeated the sentence, "Agile does not mean easy and I believe it requires much more experience to pull off than traditional processes". The book is then broken down into four parts. I have listed the parts and the chapters below. Part I- Getting Prepared Getting People On Board Using Team Consultants to Optimize Team Performance Determining Team Velocity Implementing the Scrum Roles Determining Sprint Length How Do We Know When We Are Done? The Case for a Full-Time ScrumMaster Part II- Field Basics Why Engineering Practices Are Important in Scrum Core Hours Release Planning Decomposing Stories and Tasks Keeping Defects in Check Sustained Engineering and Scrum The Sprint Review Retrospectives Part III- First Aid Running a Productive Daily Standup Meeting The Fourth Question in Scrum Keeping People Engaged with Pair Programming Adding New Team Members When Cultures Collide Sprint Emergency Procedures Part IV- Advanced Survival Techniques Sustainable Pace Delivering Working Software Optimizing and Measuring Value Up-Front Project Costing Documentation in Scrum Projects Outsourcing and Offshoring Prioritizing and Estimating Large Backlogs Writing Contracts Appendix- Scrum Framework The Roles The Artifacts The Meetings Putting It All Together Every chapter was great, but I really liked Documentation in Scrum Projects, Using Team Consultants to Optimize Team Performance, The Fourth Question in Scrum, and Outsourcing and Offshoring. All these chapters contain topics I usually see Scrum teams avoiding. A lot of agile teams like using the agile process as an excuse for not doing documentation. The author makes it very clear that documentation can rarely be dismissed. It is about doing what is needed to succeed, and planning and documentation are tools for success when they aren't over done. Too much can kill your project just as easily as doing none. The Fourth Question in Scrum rocks. This basically brings to the table all chatter that happens after the daily standup when a project is hitting rocky ground. It gives the team a chance to voice their real opinion of how things are going. The author provides a very realistic picture of what outsourcing and offshoring actually cost and how much hidden extra effort is involved. The team consultant model does a good job of showing how to structure a flexible team structure. One thing I would have liked to see more of is the inclusion of the actual practices that are executed in order to produce the documentation the author mentions. An example is architecture. The architecture documentation that results from the architecture definition process (or the Architecture Business Cycle) is just an artifact of many practices that need to be preformed throughout the entire project. The author also includes a link to supplemental material which includes some nice tools. I really like the 14 and 30 Day Sprint Backlog Templates. Over all I thought this book was great. It pulled a ton of real project experience into one place. It was also an easy read. The author's writing style made it really easy read. The stories were all interesting and were a cool way to lead into the chapter's topics.

The Scrum Field Guide: Practical Advice for Your First Year

Designing Silverlight Business Applications: Best Practices for Using Silverlight Effectively in the Enterprise Book Review

If I could change one decision Microsoft has made, it would be the one they made to drop Silverlight. Silverlight is the prefect line of business application platform for the enterprise, and this book shows us how to take full advantage of it. Although the author does an excellent job of building a case for using Silverlight over HTML5 in many scenarios, the key ingredient missing that would allow me to build Silverlight applications for my customers is support from Microsoft. Why read this book then? Because XAML is here to stay and I don't want to skip a release. I want to stay completely current even if there is no chance of building Silverlight applications with my current customers. Microsoft not saying it is dead, is not enough for them. They need to hear it will be supported before they use it again. Since that isn't happening anytime soon, neither will a Silverlight project. All that said, this book was a pure pleasure to read and shows us why Silverlight is absolutely, hands down, the best technology available today for enterprise LOB applications. This book doesn't contain any fluff. After the awesome introduction there is a Getting Started chapter. I planned on skimming this but as I started skimming I found myself repeatedly pulled into the topics. I ended up reading the entire thing. The complete list of chapters is Silverlight, Getting Started, Extensible Application Markup Language (Xaml), Advanced Xaml, The Visual State Manager, Data-Binding, Model-View-ViewModel (MVVM), The Managed Extensibility Framework (MEF), Testing, Navigation, The Service Layer, Persistence and State Management, Out of Browser Applications, Line of Business Features, and Debugging and Performance Optimization. One of the things I really like about this book is the down to earth attitude the author has. A perfect example is his chapter on MVVM. Most books I have read take the approach of over complicating MVVM. In this book the author simplifies and does a great job of explaining the pattern. One thing I didn't like was that some of the sample code didn't run right off the bat, and some I just gave up on. Chapter 10 Manual Navigation was an interesting chapter, but the way the application with the sample code was put together the application didn't load and could not be easily debugged. Some of the other samples included dlls from the feature pack 2 which requires Visual Studio Premium or Ultimate, so not everyone will be able to run them. A lot of them also require IIS Express. Most of the samples worked and they would all probably work if you want to take the time to get them working. I didn't get any of the To-Do samples to work which made up 12 of the 40 samples. Spent way too much time trying to. One chapter that began with cracking me up was Line of Business Features. The author starts off with a description of a miserable picture of what the word "enterprise" paints in the eyes of the development community. He then paints a much better picture of what an enterprise line of business development environment can look like throughout the rest of the chapter. I have seen plenty of both and the picture the author paints of how it could be is absolutely achievable. Although, most enterprises I have seen don't come close to achieving it. Developing LOB with Silverlight provides us with the opportunity to do development right. Technology absolutely plays a big part in an enterprises development environment. Where it really counts is in maintenance and enhancements. HTML (ASP.NET), CSS, and JavaScript have always produced spaghetti code nightmares in every shop I have seen use it. I know it is necessary for reach, but when you own the environments, which most enterprises do, Silverlight is the way to go. After Silverlight WPF. Microsoft is missing a huge opportunity to own the enterprise development world. They are forcing us back to two choices again, Browser spaghetti code or perceived thick client deployment headaches. Yes, the world still fears thick client deployment. They threw the baby out with the bath water when they dropped Silverlight. So my advice? Read this book. The author does a great job of showing us what we should be doing today with LOB application architecture and development. He also brings us up to speed on the latest inner workings of XAML based development. The asynchronous model will be there in Windows 8 XAML development, so learning how to use it and other features now will help you later. The author does a great job of walk us through a the most power features Silverlight has to offer and puts them into a line of business application context.

Designing Silverlight Business Applications: Best Practices for Using Silverlight Effectively in the Enterprise

Java Application Architecture: Modularity Patterns with Examples Using OSGi Book Review

Finally someone has put the most important software architecture practices into words. Within this book lies the concepts that are the heart of true agility. Without a modularized architecture, any decent size project can not achieve agility. I have seen so many agile projects flop because they ignored architecture, in particular they ignored modularization. This book also provides the keys concepts needed to ensure modifiability, the number one quality attribute for any architecture. It drives home the importance of physical design. An often overlooked aspect of designing modularity, yet it is the most important. Good logical design does not really matter if you have a poor physical design. The book is broken down into 3 parts and includes an appendix that gives an overview of the SOLID Principles. Part 1 The Case for Modularity introduces modularity and how it relates to complexity, architecture, SOA, Reuse, Design Rot, and Technical Debt. Part 1 chapters include Module Defined, Two Facets of Modularity, Architecture and Modularity, Taming the Beast, Realizing Reuse, Modularity and SOA, and Reference Implementation. The last chapter Reference Implementation shows how to apply several of the patterns through a series of refactorings applied to a sample architecture. The sample did not include OSGi. The reason the author left OSGi out of the picture is that you do not need it to design proper modularized architecture. It is a tool to enhance the runtime experience, not the design experience. I was glad the author took this approach. Part 2 of the book is the pattern's catalog. I have listed the chapter and the patterns included below. -Base Patterns: Manage Relationships, Module Reuse, and Cohesive Modules -Dependency Patterns: Acyclic Relationships, Levelize Modules. Physical Layers, Container Independence , and Independent Deployment -Usability Patterns: Published Interface, External Configuration, Default Implementation, and Module Facade -Extensibility Patterns: Abstract Modules, Implementation Factory, and Separate Abstractions -Utility Patterns: Collocate Exceptions, Levelize Build, and Test Module The pattern form (sections of the patterns) are Pattern Name, Pattern Statement, a Sketch, Description, Implementation Variations, Consequences, a Sample, and a Wrapping Up section. Part 3 of the book provides a introduction to OSGi within several contexts. Part 3 chapters include Introducing OSGi, The Loan Sample and OSGi, OSGi and Scala, OSGi and Groovy, and the Future of OSGi. The author has put up a site that includes a pattern catalog on his site Java Application Architecture: Modularity Patterns. The author has all the source code available on github. It is organized by sample/pattern name. The code is very well organized and usable. This book is not only for Java developers. It is a great book for anyone developing object oriented systems. It easily translates to .NET. I was constantly drawing parallels with my experience using PRISM to develop modular .NET applications. This is a must read for every architect and developer interested in doing architecture right. The concepts in this book will take you to a new level of quality with your architectural designs.

Java Application Architecture: Modularity Patterns with Examples Using OSGi

Programming iOS 5: Fundamentals of iPhone, iPad, and iPod touch Development Book Review

A little background so you know what type of experience I have. I have been a Microsoft .NET architect and developer since the first beta release. Before that C, C++, ColdFusion, ASP, JavaScript and of course HTML. Being a .NET developer has many advantages, but the one major disadvantage we suffer has driven me to Java and Objective-C over the past year. That one disadvantage? Microsoft themselves. They come off as completely lost and have wreaked havoc on .NET developer community the past few years. I have read several books on programming with Objective-C, but this is by far the most comprehensive and well put together. One book I would recommend to anyone coming from the .NET world is Migrating to iPhone and iPad for .NET Developers. After advising the reader to brush up on their C by reading certain parts of C Programming Language, and then spending a chapter showing how C relates to Objective-C, the author has a really nice overview of Objective-C. The overview is Part I of the book and it is 5 chapters long. The chapters include Just Enough C, Object-Based Programming, Objective-C Objects and Messages, Objective-C Classes, and Objective-C Instances. Part II IDE includes chapters on Anatomy of an Xcode Project, Nib Management, Documentation, and Life Cycle of a Project. In part II the author goes into detail about the architecture of the project and the files included in the project. He does a great job of explaining nibs, the coding environment, testing, debugging, and provides an overview of the steps taken when submitting your app to the app store. The author also points out and shows you how to take advantage of the Xcode documentation. Part III is all about Cocoa. It includes chapters on Cocoa Classes, Cocoa Events, Accessors and Memory Management, and Data Communication. The author does a great job of explaining Automatic Reference Counting (ARC) in this section. Part IV Views contains chapters on Views, Drawing, Layers, Animation, and Touches. This part is all about paths, clipping, gradients, colors, patterns, transforms, shadows, points, pixels, layers, sublayers, hierarchy, resizing, positioning, depth, borders, everything about animation, touch events, gestures, and hit-testing. In other words a ton of information about views is covered in this part. Part V Interface includes chapters on View Controllers, Scroll Views, Table Views, Popovers and Split Views, Text, Web Views, Controls and Other Views, and Modal Dialogs. The understanding you gain of view controllers in this part of the book is amazing. The author did an awesome job explaining them and how they relate to rotation. Part VI introduces some of the other Cocoa frameworks available including Audio, Video, Music Library, Photo Library and Image Capture, Address Book, Calendar, Mail, Maps, and Sensors. Part VII is called Final Topics. In this part of the book the author introduces Persistent Storage, Basic Networking, Threads, Undo, and includes an Epilogue. The downloadable code is very well organized and usable. It is broken down into folders by chapter and page number which makes it very convenient to find the sample you want. This is by far one of the best programming books I have ever read. The author's approach and writing style made it a pleasure to read. He does a great job of explaining complex topics and always covers everything in depth. If you are an iOS 5 developer, you owe it to yourself to buy this book and keep it at arms length!!!

Programming iOS 5: Fundamentals of iPhone, iPad, and iPod touch Development

Software Engineering Best Practices: Lessons from Successful Projects in the Top Companies Book Review

I have been wanting to read this for a while now but have not had the time. Although my current review is of a book 3 years old, the book is just as relevant today as it was then and will be for a long time to come. If the author gets his way, it will be relevant until 2049. He has included a chapter title "A Preview of Software Development and Maintenance in 2049". This is a massive book filled with tons of knowledge and wisdom accumulated from years of experience. The author does not pull punches. He tells it like it is. He covers what is working in the industry and points out what isn't. He also writes in a way that makes the book a very enjoyable read. At certain points in the book I forgot I was reading an IT book. Below are the chapters included in the book. Introduction and Definitions of Software Best Practices Overview of 50 Software Best Practices A Preview of Software Development and Maintenance in 2049 How Software Personnel Learn New Skills Software Team Organization and Specialization Project Management and Software Engineering Requirements, Business Analysis, Architecture, Enterprise Architecture, and Design Programming and Code Development Software Quality: The Key to Successful Software Engineering After chapter one which introduces and defines software best practices with topics like what best practices are and how you can evaluate them, different paths for software development, deployment, and maintenance, and a nice ranking of methods, sociological factors, and practices, the author lists and defines 50 software best practices. Some of the best practices included in the 50 listed include: Minimizing Harm from Layoffs and Downsizing Motivation and Morale of Technical Staff Motivation and Morale of Managers and Executives Selection and Hiring of Software Personnel Appraisals and Career Planning for Software Personnel Early Sizing and Scope Control of Software Applications Outsourcing Software Applications Using Contractors and Management Consultants Selecting Software Methods, Tools, and Practices Certifying Methods, Tools, and Practices Requirements of Software Applications User Involvement in Software Projects Executive Management Support of Software Applications Software Architecture and Design Software Project Planning Software Project Cost Estimating Software Project Risk Analysisr Software Project Value Analysis Canceling or Turning Around Troubled Projects Software Project Organization Structures Training Managers of Software Projects Training Software Technical Personnel The book is worth buying just for the list of 50 best practices. The next chapter is just down right cool. It is a preview of software development and maintenance in 2049. Topics include Requirements Analysis, Design Circa, Software Development, User Documentation, Customer Support, Deployment and Customer Training, Maintenance and Enhancement, Software Outsourcing, Software Package Evaluation and Acquisition, and many more. They are all based on what they will look like in 2049. The chapter How Software Personnel Learn New Skills is invaluable to everyone involved with software engineering. It shows what techniques are the most effective when trying to learn new technology and skills. Some of the techniques include Web Browsing, Webinars, Podcasts, and E-Learning, Electronic Books (e-books), In-House Education, Self-Study Using CD-ROMs or DVDs, Commercial Education, Vendor Education, and Live Conferences. That is just a few of them. He includes a prognosis and an explanation of each that range from several paragraphs to several pages. He also ranks each with the following- Costs, Efficiency, Effectiveness, Currency, and Overall Score. All of the chapters and topics are extremely valuable and interesting. I have never seen a book like this before and I am so glad I decided to read it. One of the things I really like about the book is all the statistical data included. There are tons of tables showing how different types of data rank. Some of them include Major Cost Drivers for Software Applications, Evaluation of Software Methods, Practices, and Results, Best Practices for IT Projects and Embedded/Systems Projects, Software Methods and Practices Considered “Professional Malpractice”, Software Knowledge Areas, Software Specialization in Large Software Organizations, Distribution of Software Specialists for 1,000 Total Software Staff, Twenty-Three Kinds of Maintenance Work, Chronology of Programming Language Development, and Sample of 150 Applications Sized Using Pattern Matching. That was just a few of them. This is one of those books that should be read by every person with a relationship to IT. Testers, CIOs, CFOs, developers, architects, project managers, and agilists will benefit from this book. I highly recommend reading it. You will come out the back end of it with a complete new perspective on Software Engineering.

Software Engineering Best Practices: Lessons from Successful Projects in the Top Companies

Microsoft SharePoint 2010 Web Applications The Complete Reference Book Review

I must admit I was misled by the title of this book, but it was my own fault. I was in the middle of developing an ASP.NET application that was using a lot of the SharePoint web services and the SharePoint Server Object Model. Although it used all SharePoint data, my application was completely separate from the main SharePoint site and completely built with ASP.NET outside of SharePoint and the SharePoint Designer. In my mind I wanted this book to be all about that and I allowed the title to make me believe it would be. Although the book was not what I expected it is still a great book to read and keep handy on your shelf. This book does cover using the SharePoint Server Object Model, but it also covers much more. It includes building SharePoint solutions with all the tools available, not just ASP.NET like I was hoping it would. The book is broken down into 5 parts. I have listed each part along with the corresponding chapters below. Part I: Introduction to SharePoint 2010 Development Chapter 1. The Microsoft SharePoint 2010 Platform Chapter 2. Developing with SharePoint 2010 Part II: Presentation Layer Chapter 3. Presentation Layer Overview Chapter 4. Client Object Model Chapter 5. InfoPath Forms Services Chapter 6. Enterprise Content Management Chapter 7. User Interface Customization Part III: Application Services Chapter 8. Application Services Overview Chapter 9. Service Application Framework Chapter 10. Word Automation Services Chapter 11. Workflow Chapter 12. Excel Services Part IV: Data Access Layer Chapter 13. Data Access Overview Chapter 14. LINQ to SharePoint and SPMetal Chapter 15. Business Connectivity Services Chapter 16. Enterprise Search Chapter 17. User Profiles and Social Data Chapter 18. Business Intelligence Part V: Configuration Chapter 19. Packaging and Deployment Model Chapter 20. PowerShell My favorite part of this book was the coverage of LINQ to SharePoint and SPMetal. That is rarely covered in most of the SharePoint books out there. The rest of the topics in the book are very well covered also. Every chapter is packed with samples. That leads me to the part of the book I was not found of and that was the code download. There are samples for chapters 2, 3, 4, and 9. Like I said above there are tons of samples, but they aren't included in the download. The book covers a ton of topics and but only covers them in depth enough to give you a clear understanding of the topic without going overboard with details. That keeps you moving and the book a bit lighter than most of the SharePoint books with this much coverage. All in all I highly recommend adding this to your SharePoint 2010 library.

Microsoft SharePoint 2010 Web Applications The Complete Reference

C# 4.0 The Complete Reference Book Review

This book is all about C# the language and some of the .NET Framework class library. It is broken into two parts. Part I introduces C# with a view into the language's history. It then spends 19 chapters covering C# in detail. It begins those chapters with an introduction to object oriented programming, encapsulation, polymorphism, and inheritance. Part II digs deep into the .NET Framework's System namespace, collections, multithreading (including the Task Parallel Library and PLINQ), and networking. I have listed the book's chapters below. Part I: The C# Language Chapter 1. The Creation of C# Chapter 2. An Overview of C# Chapter 3. Data Types, Literals, and Variables Chapter 4. Operators Chapter 5. Program Control Statements Chapter 6. Introducing Classes and Objects Chapter 7. Arrays and Strings Chapter 8. A Closer Look at Methods and Classes Chapter 9. Operator Overloading Chapter 10. Indexers and Properties Chapter 11. Inheritance Chapter 12. Interfaces, Structures, and Enumerations Chapter 13. Exception Handling Chapter 14. Using I/O Chapter 15. Delegates, Events and Lambda Expressions Chapter 16. Namespaces, the Preprocessor, and Assemblies Chapter 17. Runtime Type ID, Reflection, and Attributes Chapter 18. Generics Chapter 19. LINQ Chapter 20: Unsafe code, Pointers, Nullable Types, Dynamic Types, and Miscellaneous Topics Part II: Exploring the C# Library Chapter 21. Exploring the System Namespace Chapter 22. Strings and Formatting Chapter 23. Multithreaded Programming, Part One Chapter 24. Multithreading Part Two: Exploring the Task Parallel Library and PLINQ Chapter 25. Collections, Enumerators, and Iterators Chapter 26. Networking Through the Internet Using System.Net Appendix A. Documentation Comment Quick Reference The thing I like best about this book is the way the author is able to use reasonable size examples get his message across and that there is a sample for everything. There is tons of code in the book. One thing I did not like was the lack of the use of the using statement to properly dispose of objects. The author mentions that it should be used, but doesn't make use of it. The reasoning is he wants to show you how and where things should close without using it. That is fine, and should be shown once, but I would have preferred the majority of the examples showing it being used. The downloadable code is in the form of text files. Each chapter has a file. The samples are in the order they are found in the book. In the sample files they number each listing, which is nice, but it does no good since they aren't numbered in the book. Nevertheless they are easy to find and all of them are console application that can be cut and pasted into a console application for running. The authors writing style makes this an easy read. He does a great job of explaining complex topics. The book is good for beginners and as a reference for advanced developers. All in all I highly recommend this book to every C# developer!!!

C# 4.0 The Complete Reference

Why is Scrum so widely adopted and so very dangerously deceptive

I was sitting in a meeting sometime ago with a company that was embracing Scrum like a ten year old being offered a warm plate of chocolate chip cookies. They were grabbing at it as fast as they're little hands could reach out and grab the goodies.

Watching this made me wonder what is was about Scrum that made them embrace it so emphatically. They had claimed to be an Agile shop for years, but were still failing to deliver quality software on time with in budget. Over the past years they refused every single proposed process improvement recommendation made by dozens of consultants. They literally went from zero process (using the name Agile to execute no process at all) to zealot Scrumbots overnight. After spending some time pondering this and interviewing a few people I found the answers I was looking for.

Scrum was allowing them to preform the magic trick of perceived success better than they had ever been able to before just using the generic fake Agile process. A scary realization. This of course was not the fault of the Scrum process. It was the team's refusal to truly change anything except a few timelines, titles of individuals, and a few names like iteration to sprint.

First lets look at the developers. Scrum did not require the developers to change anything they were doing except code less in a given iteration (now called sprint) because the only required change imposed on them was shorter deadlines. They were still not required to adopt agile programming practices, because the scrum process they implemented didn't advocate for change at a developer level, only a middle management level.

No code reviews, no difference in testing, no difference in the use of patterns or TDD, no difference in anything except, now missed deadlines were written off to "we are not only agile we are Scrum, push it to the next sprint". Bugs… they don't exist, they are errors or simply new requirements that need new user story written for them. Of course their favorite part of the process they implemented is that there is no design or architecture involved. Just cowboy coding as fast as their little fingers can spew the crap out to the screen.

Project managers were renamed Scrum Masters. They were not given the responsibilities of the role of Scrum Master as defined by scrum. They simply changed role names and continued to project manage.

Upper management doesn't care. They are planning the same and paying the same prices for projects. They are getting reports that improvements are taking place, but don't bother to look at the bottom line which isn't actually changing.

None of the several projects run under Scrum have come in within budget, on time, or any less buggy. It just shows me that the same thing I have watch over the years is still happening with software development process. Most places are only pretending to adopt them. The same sad truth remains, that they actually usually think that they are changing. They are whole organizations in denial about their development environments.

Like I said above this is not the fault of Scrum. I have seen it make improvements, but only when change actually happens. It must happen at the upper management level, the project (middle) management level, and huge changes have to happen at the developer level. Architecture on any decent size project is just as important as it ever was, so to think you can do without it is naïve and shows immaturity. I have been seeing the Waterfall syndrome happening way too much with Scrum. People look at the picture and read a few lines of information about the process and think they got it. Waterfall was iterative, people simply did not read the entire paper behind the diagram. Scrum needs much more implemented than the time management aspects shown in the diagram.

Agile processes require agile development practices, which include architecture and design. Without them, you are only pretending to execute Scrum. I would recommend taking a look at the Scaled Agile Framework. Scrum is one small blip in the big picture of enterprise development.

How do you avoid this company's same fate? Bring in an outside consultant who knows software process engineering and put them in charge. Your team's best thinking have gotten them to where they are today, if that is not where you want your company to be, their best thinking won't get you anywhere different tomorrow. I have now seen Scrum transform one organization's development team and process, but that team brought in a consultant and allowed that consultant to lead the initiative. Although there was some resistance to the changes being made, because a majority of the team went along with them, the rest eventually followed.

I do not believe Scrum offers anything more than any other process including OpenUP, the Unified Process, RUP, XP, etc. Where the difference between success and failure lies is in the implementation of them, actually executing them with someone who has successfully executed them on multiple projects, and your willingness to take and execute their advice. That will mean change. Change in skill sets of your people, or change in your people, but to believe you can go from using no process to implementing any of these processes without help and changing is just naive and guaranteed to fail. That is unless you fake it like the company from this blog did and so many others I have seen do.