Friday, February 10, 2012
I’ve just spent more time than I expected getting this to work. It seemed like it would be easy, since running
cucumber from the command line is so easy. But
ant is very helpful in sanitizing the environment for subprocesses–a little too helpful, perhaps. After chasing a number of dead ends and increasingly complicated detours, I ended up with this target: (Continued)
Wednesday, May 25, 2011
Teams new to Agile often realize that they have a lot to do before they get their new development process at full speed. Looking at this big and unknown hill in front of them, many Agile teams choose to do an Iteration Zero (or Sprint Zero) to prepare before they start delivering regular increments of functionality. During this time, they may try to get their ducks in a row with
- A list of features to be built
- A release plan or timeline for those features
- Setting up development infrastructure such as version control or continuous integration servers
- Studying or practicing skills in new technologies they expect to use
- … and other management, infrastructure, and technical endeavors.
They try to get all the preliminaries out of the way so they can hit the ground running full speed in Iteration One. In my experience, they’re still not ready to go full speed. These things are rarely as complete as expected after one iteration, and often aren’t quite in tune with the actual needs of the project. The list of features will likely not be complete, but the attempt to approach completeness will dump in lots of ideas that have been given little thought. Any attempt to project into the future still has no data about how fast things can be accomplished. The infrastructure may or may not be the best for supporting the project, but it is likely that the project will now conform to the infrastructure rather than the other way around. The choice of technologies will be made speculatively rather than driven by the needs of the project. While we may do OK, we’ll have made a lot of decisions with the least amount of information we’ll have in the project lifecycle.
And we’ll have burned an iteration without producing any working software that tests our decisions.
My advice is to borrow an idea from Lean and look at the situation from the output point of view. Ask yourself, “what would it take to start delivering?” (Continued)
Wednesday, March 31, 2010
A recent post on the scrumdevelopment yahoogroup got me thinking about the age-old problems of distributed software development. The author of the post described having a Product Owner in California, developers in CA, TX, NC, & India, and QA in India. (No mention if all of the workers in India were in the same place.) I’m not picking on this individual. I’ve heard similar stories many times.
It reminded me of something I’d read in Martin Fowler’s book, Patterns of Enterprise Architecture. On page 88, figure 7.1 shows a common but distressing architectural design of distributed objects. In the diagram, the components for Invoice, Customer, Order, and Delivery are each deployed to separate machines. Why do it this way? (Continued)
Sunday, July 26, 2009
Bob Payne and I talk about continuous integration on the Agile Toolkit podcast.
Monday, July 30, 2007
I’ve never really liked stored procedures. I always put it down to the fact that I’m a programmer, not a database person. I like keeping the functionality in the code. The database is just a place where objects go when they sleep.
My current client uses stored procedures for all database reads and writes. It probably made sense when the code was ASP, but Java JDBC code has all the expressibility you could want.
Today, I learned a new reason to not like stored procedures. (Continued)