Saari Development

The frisson never died. The excitement kept me turning one page after another. Andy Hunt’s Pragmatic Thinking and learning : Refactor Your Wetware is life changing and I highly recommend it to all Software Developers new and old.

Pragmatic Thinking and Learning (PTL) is full of ideas and insights. It is based on a lot of research and background reading. It would save you a lot of trouble of going through a lot of books and research to learn the same material which might not be written this well. I had already read some of the books mentioned in the book, some were on my candidate list and some I added to my candidate list based on citations from this book but this is a concise collection of all these tips and tricks you learn from all these books (some of them I will never read as they are research on neuroscience and nursing professionals).

What does Pragmatic Programmer and Pragmatic Thinking and Learning have in common besides practical advice, tons of insight and being my all time favorite books? Andy Hunt. Andy is awesome. Not only he writes well he is a very articulate speaker. In fact the way I got introduced to this book while it was being written was a talk he gave at my company. This book is so much more than that talk I loved.

I will write more about the practical tips as I act on them in the future in this blog or on my twitter but for now I just wanted to give a shout out for this fantastic book.

If you want to buy it from my favorite book seller online here is the link.

Software development is the act of converting thoughts into actions. In other words goal of software development is to convert requirements into code but this can’t be done in one step and in a single iteration.

Each iteration in the software process you need to get a piece of requirement convert it into design, write a test, add new code and potentially refactor existing code to implement it.

For every piece in each iteration you want to follow the ordered sequence of correctness, completeness and performance. In other words, get it right, get it working, get it fast.

When understanding the requirement you want to make sure you are getting the right requirement basically understand what customers want not what they think they want. Often in requirement gathering phase the customer is biased to what they are used to or how they want something rather than letting you know the input and output they desire from a feature. Your job is to get to the bottom of it by asking good questions.

In the context of requirements completeness means that you not only understand the input and output but the entire context to implement the feature correctly. Once you understand what and in what context only then you turn your attention to performance requirements (if any) as discussion of performance earlier might not be in context and well understood where the customer is coming from. All these discussion do not have to happen at the same time but in should happen in that order.

I think I have already explained the hardest part in the whole iteration. Requirements is often where we get it wrong and the hardest/most-expensive one to correct after the fact.

When it comes to writing code you also follow this sequence, make sure you are implementing what you intend on implementing by writing unit tests first. The act of trying to write test first often force you to think about what you are about to do. You repeat this process until you have met all the requirements for the feature (completeness) and only then you measure performance and do any performance tuning if necessary. Software developers are not only often guilty of the thought crime of premature optimization but actually commit this crime if not stopped in time.

Do you think my thoughts are incorrect, incomplete and would not scale? Please send me a thought patch in the comments.