Archives for category: Software Development

One of the arguments that I see a lot in favor of Test Driven Development is that it helps deliver higher quality software more quickly. The more I projects I take part in or observe, I realize that this is only half true, and less than half true for Agile projects. I’m not saying that TDD has no place in Agile projects, just that it has a very specific place and time.

Read the rest of this entry »


One of the causes of death march project is poor story definition. Whether you call them stories, features, tasks, items or whatever, defining good stories is essential for success.

The ACID principle from database design applies to stories as well as databases. Atomicity, Consistency, Isolation and Durability. These principles apply to story design as much as they do to anything else.

Read the rest of this entry »

After 20 years off earning my daily bread writing software, it’s still thrilling to start a new project.  That feeling of hope, knowing that this time we’ll do it right rather than cut corners and choose good over expedient. Every new beginning makes me think of what should happen, and reflect a little on what makes good work. That gets me thinking about what makes quality software.

One of the most important things in any endeavor is solid fundamentals. Whether it’s playing a sport or writing software, the basics matter. Always.

Read the rest of this entry »

Engineering Long-Lasting Software: An Agile Approach Using SaaS and Cloud Computing, Alpha Edition

It’s an interesting primer on Ruby on Rails, test driven development and agile development. It’s geared at undergrad computer science students and does a good job for that.

However, as an experienced professional, I was looking for many of the chapters that aren’t written yet. For example, the chapters on creating testable javascript and writing maintainable client side code were missing. In a nutshell, wait for the beta edition if you already know rails.

I thought that it was an interesting experiment in lean writing.  The idea was to write just the chapters that you need now and see what the interest is in the other chapters.  It will be fun to see what happens in future versions of the book.


I’ve been reading Wait: The Art and Science of Delay it’s been giving me some food for thought about the strange world of software development. Basically, the thesis of the book is that there is a correct amount of delay between the action and the response to the action. The time scale is kind of irrelevant, whether it’s the milliseconds between someone serving a tennis ball and returning the serve, or the days between making a mistake and apologizing.

Read the rest of this entry »

We use mercurial in kind of a hub and spoke manner.  A central repository that everyone pushes to, and branches for the main processes, development, QA, production, etc. All the developers pull the latest from the central repository, commit their changes and push them back to the central repository.

Read the rest of this entry »

I’ve been thinking a little about documentation recently. In some ways, documentation is like the parable of the blind men and the elephant. Where the elephant is the concept being described and the blind men are the artifacts being produced. Each of the documents captures a facet of the whole, but not the whole thing.  Every piece is an incomplete view of the whole item but taken together they describe a much larger concept.

Read the rest of this entry »