The Phoenix Project (Book Review and Lessons Learned)

If you're a professional developer, or just a developer, you should read this book, and you will probably enjoy it very much. It should also make you a better developer.

If you're a IT manager, you should REALLY read this book... because if you don't understand these concepts and implement them, you will probably have an inefficient project and/or team:  slow, buggy, and complex processes; unmanageable and unscalable code.

This will lead you to spend the majority of your time dealing with production issues... which means less time to think about coding... which leads to lower quality, untested code... which leads to more issues which... ultimately causes you and your team to not getting enough sleep because you're always on issue calls at 3AM in the morning... which ... need I continue?

I think they call this the un-Virtuous Cycle.

For me after reading this, clearly my point of pain was in the lack of testability in the existing code that I inherited. Without tests, you weren't sure if even a minor change would have dire consequences.. until it was release and complaints start coming in.

Because the code already exists though but testability was not something that was considered at all, I couldn't directly integrate a testing framework like NUnit; would have had to rewrite some core parts which is just too risky...

Which leads to another consideration when coding and also why you should have unit tests:

As more code relies on a single function, it becomes harder to change... unless you have unit tests that cover all possible existing uses, in which case it should be very easy to make sure existing functionality isn't broken.

The other thing about testing, and also automating the build process is that it shortens release cycles. These activities usually have a  relatively fixed cost, it doesn't matter whether the change is big or small. So reducing the these times makes it easier to do a release, so you can do more smaller releases instead of doing huge releases that contain multiple changes.

You can't fight human nature: we want to get things done the quickest and least painful way possible. Automation let's you do that while not impacting quality.

Yes this is kind of getting off-topic from the book itself but I feel, at least for me and with my own experiences, that it opens the door to all these ideas.

There is a saying that lazy programmers are the best programmers. It probably should be lazy but smart programmers. Understanding and implementing the ideas and in The Phoenix Project should make you one of the latter.

Amazon The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win