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 »

Halfway between single class unit testing and end to end acceptance testing is a grey area that for now I’m calling Unit Acceptance Testing. Basically it’s a unit test that instead of isolating a single class or layer under test, tests several layers and the way that they interact.

Read the rest of this entry »

Fixed time, fixed price development is really about managing the project across sprints to make sure that you hit the finish line at the right time. Except in the most trivial projects that can be done in a single sprint, this will involve coordinating and planning across multiple sprints until the release date.

That pretty much makes the strategic planning aspect of managing the project the most important part.  It seems like most of the time the planning runs into issues it comes down to a choice between two excuses:

  1. It’s taking us longer than we thought. (bad velocity tracking)
  2. We need to add this other thing before we can move on. (scope management)

Read the rest of this entry »

 

The interesting thing about doing fixed time, fixed price agile development is that it’s just agile development turned out to 11. All the same practices that you should do when doing any flavor agile, but usually don’t are critical to working fixed price. Probably the key practices to follow are: tracking velocity, scope management and multi-sprint strategic planning.

Scope management is the second most important part of doing successful fixed time fixed price development, or any development for that matter. Scope is essentially the “definition of done” for the business process.

The definition of done for a task is defined by the team as incorporating certain things: unit tests, integration tests, documentation or whatever. When all the criteria for “Done” are met, the task is done. Scope is the same sort of thing, just for the entire project. When all the things that are in scope are done, the project is done.

Read the rest of this entry »

I always wonder when I see another article about how it’s impossible to do Agile software development on a fixed time/fixed price basis. Especially because I’ve spent 75% of my career doing exactly that. The thing that really gets me is when people write that the only way to do accurate estimation is to have complete and detailed requirements up front. As if having 400 pages of cut and paste business speak to adhere to is going to magically solve the problem.

The interesting thing about doing fixed time, fixed price agile development is that it’s just agile development turned out to 11. All the same practices that you should do when doing any flavor agile, but usually don’t are critical to working fixed price. Probably the key practices to follow are: tracking velocity, scope management and multi-sprint strategic planning.

I realized after starting this that this is a big topic and should get split into multiple parts. So here’s the most important, or at least first part.

Read the rest of this entry »

The martial arts school that my wife and I, Academia Duellatoria, go to just did a weekend of demos and free lessons at the Faire in the Grove. At the time, I was thinking that it wasn’t as successful as I would have liked it to be. Until I thought about it some more later.

Read the rest of this entry »