Software Development with Linux

Book Review: Code Complete

MON, 23 DEC 2013

I just finished reading Code Complete: A Practical Handbook of Software Construction, Second Edition by Steve McConnell. You are probably already familiar with that book; it is a "recent" classic.

For those who have not read it yet (like myself a couple of months ago), I'd like to say that this book is up to its reputation. It is really a complete book. I can't think of a topic that should have been discussed in it that was not. It does not have endless details about each topic, that is true, but it still gets into more deep than many books that try to cover all the aspects of software development.

I think the best way to see this is as a great first step into many topics related to software development. You can skim through chapters when they covers things you already know very well, or read carefully chapters when you do not have as much knowledge about the question analyzed. For new software developers, they should probably read it front to back.

But whatever your level of experience is, you will certainly find some new things to learn from it. Maybe you will found that this amount does not worth the price of the book, but in that case, you surely know some people new to this field, so give them the book!


Compilation as a test

MON, 16 DEC 2013

A recent discussion in the Agile and Lean Software Development group on LinkedIn started with the question, Do we loose agility with a long build time?

While most of the discussion was around the pros and cons of using language that don't have to be compiled or why people do not want to put the time it takes to improve their existing build system, I think one thing overlooked was : why do people consider compilation as anything but a special test case?

If you consider that compilation and building steps are actually (mandatory) tests, then all the usual thinking you have about test length apply. Do you have a single big test that test everything each time you change a single line of code? Obviously no. Do you think it is valuable to cut tests into smaller pieces and execute only those that apply to a change instead of the whole lot every time? I do and you probably think the same.

In that case, why are you allowing to have a big compile time every time you change a single line of code? All the build systems (that I know of, that is) allow for good dependencies tracking and conditional compilation, so the tools are already available. So if the compile and build time is too long for your software development method, attack that like a big test you have to run and chunk it into acceptable pieces. This have been done for many years now already, so take the couple of hours you need to learn your build environment and compilation tools, and do it the right way.


Book Review : Version Control by Example

MON, 13 MAY 2013

I have read Version Control by Example from Eric Sink a couple of months ago, but let's talk about DataBallet first.

I am happy to have finally moved to DataBallet's NEWS engine for this blog. The main issue was that I needed to migrate all the previous (around 200) posts from flat HTML files to templates and database content. I guess the reason why it took so long to do so was that it wasn't something particularly interesting to do... But at last, this is now done so I will now be ready to share thoughts and other things here. So let's move to the book review.

Published in 2011, the book discuss version control tools, more particularly distributed version control tools. On interesting point of the book is that it does a great comparison of centralized version control tools and distributed version control ones. The same function is described for both, so you can easily see where the differences are, what benefits you get from each, etc.

The first part of the book talk about the basic usage of a centralized version control tool, using Subversion (aka SVN) for examples. The second part of the book cover the exact same functions (commit, checkout, log, etc.) but using distributed version control tools, using Mercurial, Git, and Veracity. Finally, branching workflows and how a distributed version control tool works under the hood is covered in Part 3.

All in all, this book is easy to read. If you are looking for an introduction to distributed version control, and prefer to read it from dead trees or wants to enjoy the many puns and jokes inside, that is a good choice. But, don't be surprised once you've been through it that you only skimmed the topic. Also, the fact that the all the version control functions are described in details for 4 different tools, well, this can a bit boring to read depending on your knowledge level. As of today, the book is priced at around 31$US on Amazon.com. I don't think it is worth that much. If you can get a copy in the range of 10$-15$, that would be alright. A better deal is probably the PDF version available from the author's web site. Judge by yourself if it is worth the paper copy price.


Book Review : Rapid Development

FRI, 23 NOV 2012

One of the good thing about book, is that there is so much good book available, that there is always more good books left to read the number of books you have already been though. Another good thing about books is that good books stay good even as the time goes on. Rapid Development: Taming Wild Software Schedules by Steve McConnell is one of those good books that, while written more than 15 years ago, is still an excellent read today. Actually, reading it now allow us to have a better perspective on the different best practices mentioned by Steve.

Because that is what this book is really about: what are the best practices to achieve rapid software development. But to know which ones are the best practice for your project, you need to know how to select them, what are the hypothesis behind the idea, and where they are best applied. Fortunately, this is also covered in detail in the book. In fact, I do not see what could have been added to this book; it feel really complete.

Even with some best practices that you can see would need to be modified to be applied today, or maybe even not that much useful with all the changes the software development industry have seen, it is still a most excellent read. I recommend it to everyone that have some impact on or is affected by any software development project. From fresh out of school to experienced professionals, this book is a must read for everyone.


Kanban and Scrum: making the most of both

THU, 15 NOV 2012

I recently read Kanban and Scrum: making the most of both. That was actually the first time I read something detailed about Kanban. What I particularly loved from it is that it does not try to make you believe in a silver bullet. I know that all (at least, most) knowledgeable people understand that silver bullets are only mythical and unreal, but that fact is sometime hidden when personal interests are at stakes. One could have expected that a book about Kanban and Scrum would preach that Kanban and Scrum are the solution to every problem. Fortunately, that is not the case.

The book is split in two sections. The first part describe both Scrum and Kanban individually before comparing them so you have a clear picture of the similarities and differences. The second part is a case study, which is probably the best way to show how you can use the two together. Again, there is always an explanation as to why something was chosen, and why you should decide for yourself what you need.

At 122 pages, with plenty of pictures and diagram, this can be read in only a couple of hours. You won't be an expert in Scrum or Kanban after that, but you will know enough to start experimenting on your own. Nothing beats learning by doing. Nothing.


Browse older posts.