Write a Book Exactly as If You're Developing Code

A book is a product and writing books is exactly the same as developing a product. I'm using XP and Agile technical practices and techniques to write my first book . Guess what? It works perfectly!

The story started sometime ago when I heard about LeanPub. It was cool and I thought I'll use it once. Now, I'm actively writing, or rather developing my first book: Refactoring to Clean Code:

The experience is very similar to developing a software product. Or, I can say it is exactly the same.

I'm not gonna talk about the book topics as features which may or may not suite your target customers, and how you should frequently pivot your strategy till you reach a solution market fit. These are very obvious similarities. Rather, I'll talk about the actual development of the book, producing book chapters, which is very similar to writing code modules.

I'm using version control, issue tracking, and full traceability (using github). I'm also using continuous deployment. Hah? yes, it is that black magic in software which enables features to be instantly deployed on production with very little overheads (for this, I use automated hooks which links githup with leanpub. Leanpub automatically generates a new version of the book upon every push from my side on github)

Finally, I'm using a full fledged development environment (Atom) which has realtime linter to check bugs on the fly (spelling and grammar mistakes). Atom in connects directly to github. So, I develop and commit changes on the same window.

Later on, I will prepare a test environment for my early adopters and reviewers. They will receive special editions from leanpub. They may open issues on githup, and even they may fix parts of the book and send me pull requests on github :)

Those who love coding, if they thought of the book as a software product, they will love writing as well :)

Would you like to become a reviewer (or early adopter)?

If you would like to become one of the early adopters, please let me know. Here is a link to the book with highlights about the contents:

https://leanpub.com/RefactoringToCleanCode

Ground Rules for Refactoring Legacy Systems

If you have a very poor code which is buggy, cluttered, ugly, scary, etc. If you have such code,  do one of the following:

1. Sunset this application
2. Ask your customers to stop asking for changes and fixes
3. Quit your job and switch to a more convenient one (other than software of course)

If you can't do any of these, then you're stuck with refactoring this code base. This is possible and even exciting.

Here is a set of ground rules to take into consideration before you start doing that:

1. Zero "more" defects policy: That is, stop working the moment you find the next bug, and fix it immediately. The rule is adapted from the Zero defects policy! which is a bit overwhelming at this stage.
2. Any "new" code must be covered by tests. Period.
3. Peer review is part of our DNA (till we're able to automate parts of this review, or all of it)
4. The Boy-Scout Rule applies to all of us. 
5. Automate all donkey work, one script at a time! That is, everything we do in a systematic way, can be scripted. What we should do is to automate all this work. 

If you do that, you'll find things slightly improving at the beginning, but exponentially improving later on, insha'Allah :)

How to find dead code?

Recently, I have read this interview with Kevlin Henney, an independent consultant and a great developer.

These are some very good insights about ways to find dead code:

1. Static analyzers are a good start
2. Search for files that has never changed since a while. "There are many reasons code may be stable — it’s just right, it’s just dead, it’s just too scary — but unless you investigate you’ll never know."
3. Runtime monitoring and Dynamic program analysis may be used to rule out parts of the code which is not dead code, effectively reducing the code under investigation

One very interesting note is that:

"Deleting dead code is not a technical problem; it is a problem of mindset and culture."

Furthermore, in this very interesting lecture by Kevlin, he tells the very famous story about Kinght corporation which lost hundreds of millions due some dead code left over. Also, narrates some very interesting stories alike. I highly recommend any developer to watch this lecture.  

I'm Speaking at Agile2016

I'm glad to announce that I will be speaking at the Agile Conference - Agile2016 organized by Agile Alliance. This is the biggest agile gathering in the world, featuring more than 2000 attendees and 200 sessions.

I will be running a technical workshop titled: Detecting and Preventing Code Clones Mercilessly, at which I will go through different types of code clones and how to detect and prevent them.