Category Archives: Software Theory

Dreaming In Code

I just finished reading Dreaming In Code by Scott Rosenberg today. In short; I liked it!

The book is an exploration of the pitfalls of developing and managing software projects. It follows several years of development on the Chandler Project by the OSAF asking questions such as:

  • Why are software projects rarely delivered on time?
  • Why are software projects rarely delivered with all of the desired functionality?
  • Why is it that software projects very rarely meet the users desires?
  • Why do software projects always seem to fail in some way?
  • Etc.

Rosenburg draws upon his personal experiences, the experiences of the Chandler project and the collected wisdom of software’s sages (such as Frederick P. Brooks) presenting the reader with enough information to conclude their own answers to the questions presented in the book.

Dreaming in Code is a light, fun and enjoyable read. Easy to pick up for short, or long, periods of reading this book delivers similar messages to those in other works on the topic of software management but presents them in such a way the reader is likely to feel like they have experienced enough to draw the conclusion themselves rather than being told that it is so.

Great book, fun read and highly recommended. Whether you are an in the trenches programmer looking for an outside view or a managerial type who just can’t understand why the developers can never deliver their projects on time.

Tools Geek

I think I’m becoming a bit of a programming tools geek, spent a bit of time over the weekend reading Understanding Darcs over on Wiki Books.

I found the section on patch theory interesting and I’m looking at using Darcs for my personal projects for a while, see how I get on.

I also engaged in several discussions at work last week about source and version control tree structure. I was eventually convinced that our existing vc tree is the right one for us, but only once each of my arguments had been justified. It’s a pretty non-traditional source tree structure which represents our need to rapidly release full, up-to date, builds at the drop of a hat. Nightlies are not enough!

At one stage I was contemplating overhauling the whole build process; have the subcomponents in separate trees, build bot with code coverage, nightly builds, etc. Unfortunately this is a massive job and will involve a big time commitment with the only real gain being a little more developer convenience with a slightly more logical vc tree.

Unfortunately it being an interesting project and tidying up the developer work flows is not enough of a reason when we have so much work and so little time. I agree from a business standpoint but I’m a programmer, so the missed opportunity to construct a system is a little disappointing.